> On Sep 6, 2016, at 5:11 PM, Douglas Gregor <dgre...@apple.com> wrote:
>
>>
>> On Sep 6, 2016, at 4:50 PM, Joe Groff <jgr...@apple.com> wrote:
>>
>>
>>> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution
>>>> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
