You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The compiler could reason: Well, this protocol is an Objective-C class protocol, so it is analogous to a type AnyObject. If this String/Int were assigned where an AnyObject is expected, I would cross the bridge to NSString / NSNumber. If I do that, do I get an NSSecureCoding / NSCoding adopter? Yes!
As it is, I have to say `as NSString`, `as NSNumber`, which is surprising considering how we usually cross the bridge from Swift implicitly without a murmur.
The issue arises in real life particularly because a number of Cocoa APIs do specify an NSSecureCoding parameter, but the programmer typically does not know that, passes a String or an Int, and is surprised when that doesn't work.
The text was updated successfully, but these errors were encountered:
Implicit conversions from value types to reference types were present in Swift < 3. SE-0072 eliminated these implicit conversions, which included the implicit conversion requested here. While prior decisions can be revisited via the Swift evolution process (go to forums.swift.org for such discussions), I don't think there is any chance that the Swift Core Team would accept re-introducing these implicit conversions.
Additional Detail from JIRA
md5: d03a46d5fbe7739dbe5b2c9320149b4e
Issue Description:
I wonder whether this sort of thing could be made to compile?
The compiler could reason: Well, this protocol is an Objective-C class protocol, so it is analogous to a type AnyObject. If this String/Int were assigned where an AnyObject is expected, I would cross the bridge to NSString / NSNumber. If I do that, do I get an NSSecureCoding / NSCoding adopter? Yes!
As it is, I have to say `as NSString`, `as NSNumber`, which is surprising considering how we usually cross the bridge from Swift implicitly without a murmur.
The issue arises in real life particularly because a number of Cocoa APIs do specify an NSSecureCoding parameter, but the programmer typically does not know that, passes a String or an Int, and is surprised when that doesn't work.
The text was updated successfully, but these errors were encountered: