Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-3117] as coercion should not be allowed for bridged classes with many bridged value types (NSNumber, NSValue) #45705

Closed
jckarter opened this issue Nov 2, 2016 · 6 comments
Closed

[SR-3117] as coercion should not be allowed for bridged classes with many bridged value types (NSNumber, NSValue) #45705

jckarter opened this issue Nov 2, 2016 · 6 comments
Assignees
@jckarter
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@jckarter
Copy link
Member

jckarter commented Nov 2, 2016

Previous ID SR-3117
Radar rdar://problem/29067460
Original Reporter @jckarter
Type Bug
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee @jckarter
Priority Medium

md5: 9b79ea739ac0ef094750ffdef09ccea7

Issue Description:

https://twitter.com/GFontenot/status/793611396487405568

@gfontenot notes that nsNumber as UInt is still accepted, but will crash if nsNumber is a bridged object preserving a different Swift type. We should turn this into a conditional cast so that as? or as! has to be used. (We can maintain 3.0 compatibility by staging this in as a warning in Swift 3 mode.)
@jckarter
Copy link
Member Author

jckarter commented Nov 2, 2016

@swift-ci create

@belkadan
Copy link
Contributor

belkadan commented Nov 2, 2016

Hm. It's not really about being multiply bridged; it's about being conditionally bridged. (It might not be worth making the distinction, but IIRC right now the only mapping from the reference type to the value type is the swift_bridge Clang attribute, and following that seems a bit overloaded.)

@jckarter
Copy link
Member Author

jckarter commented Nov 2, 2016

We must have this "conditionally bridgeable" concept in the compiler already to some degree, since an NSArray for instance can only conditionally be cast to Array<T> unless T is Any or AnyObject.

@gfontenot
Copy link

FWIW, there's some more info on this PR: thoughtbot/Argo#425 including some small test cases from @sharplet

@jckarter
Copy link
Member Author

Fixed in master: #6774

@jckarter
Copy link
Member Author

Working on 3.1: #6798

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jckarter jckarter

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@gfontenot @jckarter @belkadan