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

[Joe Groff]

> On Sep 6, 2016, at 5:11 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
>> 
>> On Sep 6, 2016, at 4:50 PM, Joe Groff <jgroff at apple.com> wrote:
>> 
>> 
>>> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 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?
>>> Strong -1 as is.
>>> 
>>>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
>>> Not only do I not believe the problem is significant, but I believe that the proposal *introduces* a new problem which *is* significant, which is the accidental passage of optional arrays to Objective-C. With the existing behavior, such mistakes are immediately obvious as Objective-C receives an opaque object that it cannot use (and probably soon crashes), so they are unlikely to make it past QA testing. For many other cases, particularly when nil is encountered in an array only rarely, this is likely to cause strange and hard-to-debug problems at runtime when NSNull pops up where code wasn’t expecting it (which I would expect to be most Objective-C code), and it might not be detected until after the product ships. In this way, this proposal creates a problem very similar to the problem that Swift was trying to solve with optionals in the first place.
>> 
>> This is a fundamental problem with `Any` in Swift and `id` in Objective-C. There's no way to statically prevent misuse of such APIs. We can, and IMO should, provide warnings when Optionals are used in unconstrained contexts without either being unwrapped or explicitly annotated somehow. That doesn't conflict with this proposal, though.
> 
> 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'm not sure I agree with this sentiment. It feels contrary to what you get when you put an Optional in an Any in Swift, since we consider Optional to dynamically be a supertype of its payload:

	let x1: Int? = 1
	let x2: Any = x1
	print(x2 as! Int) // prints 1

-Joe