Sent from my iPhone
> On Sep 6, 2016, at 5:21 PM, Joe Groff <jgr...@apple.com> wrote:
>
>
>>> 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
I wasn't expressing an opinion per se; just trying to clear up a perceived
misunderstanding.
- Doug, pretending to be a neutral review manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
