[swift-evolution] [swift-evolution-announce] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Joe Groff]

> On Sep 2, 2016, at 4:58 PM, Gwynne Raskind via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Sep 2, 2016, at 17:50, Douglas Gregor <dgregor at apple.com> 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:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md
>> 	• What is your evaluation of the proposal?
> 
> It seems like this would improve the utility of bridging collection types (and plist types in general), and I like that it does something more sensible than before with the disparate bridging behavior of Optional<>. But I do have a couple of questions:
> 
> Will specifying a nullable type parameter to collections now become legal in Objective-C? E.g.:
> - (void)takeOptionalCollection:(NSArray<id _Nullable> * _Nullable)collection; // Bridge to [Any?]?
> 
> If not, is there any way to annotate “I want to be able to use (or not use) NSNull in this collection”? If there is, does doing so affect any behaviors on the Objective-C side? If there isn’t, wouldn’t it make more sense to treat passing an optional to Any as requiring forced unwrapping (including the implied runtime crash behavior), as is the case with other uses of optionals now? I can’t think offhand of any use case where I would want an object, even in pure Swift, where I didn’t know whether it was an optional or not, outside of debugging.
> 
> Depending on the answers to these questions, I’m tentatively in favor of this proposal.

Changing Objective-C is outside of my power. I don't think that giving `_Nullable` a very different meaning is a good idea, though. A feature that feels more in the spirit of Objective-C would be support for class sum types, so you could say that you had an NSArray<NSString* | NSNull*>. (Similarly, you could have a `typedef (NSString*|NSArray*|NSDictionary*|NSNumber*|NSNull*) NSPropertyList;` to obviate the need for `id` for representing property list types.)

-Joe

> 
>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Honestly, I don’t feel like it is, but my opinion may not be all that valid, since I’ve spent a great deal more time in pure Swift (and interop with pure C) than in interop with Objective-C.
> 
>> 	• Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, *IF* the semantics of Optional remain consistent, which I’m not yet entirely clear on.
> 
>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I haven’t worked with ObjC bridges in other languages.
> 
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> A quick reading. I was not part of any previous discussion on this topic.
> 
> 
> -- Gwynne Raskind
> More magic than a mere signature can contain
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution