> 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.
- Doug
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
