> On Sep 2, 2016, at 4:58 PM, Gwynne Raskind via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Sep 2, 2016, at 17:50, Douglas Gregor <dgre...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
