[swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull
Fabian.Ehrentraud at willhaben.at
Fri Sep 9 09:09:19 CDT 2016
• What is your evaluation of the proposal?
In favor, as we already ran into crashes after migrating our project to Swift 3.
I'm not completely convinced though that the compiler should ignore nullabiliy markup on id. Also id has a long tradition in the ObjC community to be used instead of NSObject * which does not suffer from the problem.
• Is the problem being addressed significant enough to warrant a change to Swift?
Very much, the compiler should do everything it can to avoid runtime crashes due to programmer errors.
• Does this proposal fit well with the feel and direction of Swift?
Yes, more intelligent and useful bridging makes sense. NSNull can be problematic too, but having an Optional.some value definitely should work on the other side of the bridge too.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I even filed a Swift bug (SR-2601) before I found this proposal explaining that nullability on id is ignored since SE-0116.
On 03.09.2016, at 00:50, Douglas Gregor via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:
Hello Swift community,
The review of SE-0140 "Bridge Optional As Its Payload Or NSNull" begins now and runs through September 8, 2016. The proposal is available here:
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:
<https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution