> On Sep 6, 2016, at 7:11 PM, Douglas Gregor <dgre...@apple.com> wrote: > > I *think* Charles is saying something slightly different here, and it’s a > viewpoint I hadn’t considered before. > > We agree that there should be some kind of diagnostic when putting an > optional into an Any, because it’s probably not what the user intended. And > we know it can happen in ways we cannot diagnose statically, so the > diagnostic won’t be perfect. I think Charles is saying that, when this > happens, we don’t *want* our Objective-C code to be able to query the value > in that optional: in other words, it’s effectively a programmer error to > treat such objects as anything more than completely-opaque objects that get > passed around any perhaps dealt with properly in Swift code itself.
I’d say my position has three planks on it, and the above is pretty much the first plank: 1) the idea of an array of optionals is a concept that doesn’t really exist in Objective-C, and I do think that passing one to Obj-C ought to be considered a programmer error. The other two planks would be: 2) Bridging arrays of optionals in this manner could mask the aforementioned programmer error, resulting in unexpected, hard-to-reproduce crashes when an NSNull is accessed as if it were something else, and: 3) Objective-C APIs that accept NSNull objects are fairly rare, so the proposed bridging doesn’t really solve a significant problem (and in the cases where it does, using a map to replace nils with NSNulls is not difficult to write). Charles
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
