@gparker42, @gribozavr, was there a reason we didn't do this? Was it just to avoid confusion with %s?

vadim (JIRA User), you can work around this by explicitly coercing to NSString or AnyObject using as.

We can't make AnyObject conform to CVarArg.

Ah, right, of course. But that doesn't say why we wouldn't do it for String, and I think we do (or could) do it for NSObject, at least.

Comment by Ian Partridge (JIRA)

let args: [CVarArg] = [NSString(string: "hello world")]

doesn't compile on Linux, because NSObject only conforms to CVarArg on Darwin. Is fixing that a better way to go?

Comment by Jason Ji (JIRA)

Hello, just wondering if there was any progress on this? I also ran into an issue today where a call to

Wanted to bump this, as I've run into it too.

It'd be nice if all the bridged types conformed to CVarArg even on Darwin to avoid the as CVarArg explicit bridging conversions too.

Comment by Matthew Burke (JIRA)

One more bump^Wdata point. Just ran into this as well.

Comment by Joseph Lawson (JIRA)

A patch can be found here in the mean time:

IBM-Swift-Sunset/GRMustache.swift@56ecaf2

We ended up munging the data into the type desired with as! CVarArg:

return String(format: NSLocalizedString("Configuration Error: %1$@", comment: "The error message displayed for configuration errors. (1: configuration error details)"), details.localized() as! CVarArg)

Comment by Brian Gontowski (JIRA)

I created PR #2821 and PR #32311 to implement the CVarArg protocol on NSString and String.

There is some discussion in the Swift forums about this.

Comment by Brian Gontowski (JIRA)

The pull requests have been merged.