Skip to content

[3.0] SE-0140: Bridge Optionals to nonnull ObjC objects by bridging their payload, or using a sentinel. #4891

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.

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

Merged

Conversation

jckarter
Copy link
Contributor

@jckarter jckarter commented Sep 20, 2016

id-as-Any lets you pass Optional to an ObjC API that takes nonnull id, and also lets you bridge containers of Optional to NSArray etc. When this occurs, we can unwrap the value and bridge it so that inhabited optionals still pass into ObjC in the expected way, but we need something to represent none other than the nil pointer. Cocoa provides NSNull as the canonical "null for containers" object, which is the least bad of many possible answers. If we happen to have the rare nested optional T??, there is no precedented analog for these in Cocoa, so just generate a unique sentinel object to preserve the nil-ness depth so we at least don't lose information round-tripping across the ObjC-Swift bridge.

Making Optional conform to _ObjectiveCBridgeable is more or less enough to make this all work, though there are a few additional edge case things that need to be fixed up. We don't want to accept AnyObject?? as an @objc-compatible type, so special-case Optional in getForeignRepresentable.

Implements SE-0140 (rdar://problem/27905315).

…ayload, or using a sentinel.

id-as-Any lets you pass Optional to an ObjC API that takes `nonnull id`, and also lets you bridge containers of `Optional` to `NSArray` etc. When this occurs, we can unwrap the value and bridge it so that inhabited optionals still pass into ObjC in the expected way, but we need something to represent `none` other than the `nil` pointer. Cocoa provides `NSNull` as the canonical "null for containers" object, which is the least bad of many possible answers. If we happen to have the rare nested optional `T??`, there is no precedented analog for these in Cocoa, so just generate a unique sentinel object to preserve the `nil`-ness depth so we at least don't lose information round-tripping across the ObjC-Swift bridge.

Making Optional conform to _ObjectiveCBridgeable is more or less enough to make this all work, though there are a few additional edge case things that need to be fixed up. We don't want to accept `AnyObject??` as an @objc-compatible type, so special-case Optional in `getForeignRepresentable`.

Implements SR-0140 (rdar://problem/27905315).
@jckarter
Copy link
Contributor Author

@swift-ci Please test

@jckarter jckarter changed the title [3.0] SR-0140: Bridge Optionals to nonnull ObjC objects by bridging their payload, or using a sentinel. [3.0] SE-0140: Bridge Optionals to nonnull ObjC objects by bridging their payload, or using a sentinel. Sep 20, 2016
@tkremenek tkremenek merged commit 1f11ef2 into swiftlang:swift-3.0-branch Sep 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants