[smallduck]

Indeed the intent, though not expressed in the Objective-C declaration through the type system, is that the format string is a string literal.

However the intent of the Swift call described in the article is indeed that of a string literal with 2 data "parameters".

So is the correct use of NSLog in this case is this:

    NSLog("%@", "Failed to get modification date at URL: \(url) - \(error)")

This should really be the behavior of NSLog in Swift, that it expands not to the variadic

    NSLog(format-string-parameter, objc-object-parameters..)

but to

    NSLog(@"%@", string-parameter)

[tialaramex]

Swift explicitly knows the difference between this construction and an actual string literal. Its type system considers "Foo" to be a StaticString, while "Foo \(something)" is merely a String, because it will need runtime allocation to calculate the actual value. A StaticString is actually a cheaper representation as well as needing to be distinguished for this reason.

So a native Swift API would be able to distinguish and refuse to let you provide this String where a StaticString is the appropriate thing, I am not an Apple expert to say whether this would be possible / easy for the NSLog binding, if it was possible to do this it should have been done.

[dwaite]

In general, it is valid to resolve localized strings for use as format strings, which means that it is valid to have dynamic format strings at runtime.

NSLog might be considered an exception vs other Objective-C usage of format strings - but it might also not be worth having a singular special case.

[saagarjha]

NSLog takes dynamic strings just fine. Arbitrarily constraining it to only accept StaticStrings would break valid Swift programs. I wouldn't necessarily be opposed to it, but it's certainly not something that can be done without thoughtful consideration of the side effects.

[azinman2]

Correct would be

NSLog(“Failed to get modification date at URL: %@ - %@“, url.absoluteString, error.localizedDescription)