3 ms·

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 inte

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)

azinman2 5y ago
Correct would be NSLog(“Failed to get modification date at URL: %@ - %@“, url.absoluteString, error.localizedDescription)
tialaramex 5y ago
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.
- saagarjha 5y ago
  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.
- dwaite 5y ago
  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.

azinman2 5y ago

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

tialaramex 5y ago

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.

saagarjha 5y ago
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.
dwaite 5y ago
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.