> On Dec 19, 2017, at 8:57 PM, Douglas Gregor <[email protected]> wrote:
>
>
>
> Sent from my iPhone
>
>> On Dec 19, 2017, at 8:31 PM, Ted Kremenek <[email protected]> wrote:
>>
>>
>>
>>> On Dec 19, 2017, at 3:59 PM, Douglas Gregor <[email protected]> wrote:
>>>
>>>
>>>
>>>> On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>>> On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev
>>>>> <[email protected]>, wrote:
>>>>> Hi all,
>>>>>
>>>>> A little while back, I added an error to the Swift 4.1 compiler that
>>>>> complains if one tries to use conditional conformances, along with a flag
>>>>> “-enable-experimental-conditional-conformances” to enable the feature. We
>>>>> did this because we haven’t implemented the complete proposal yet;
>>>>> specifically, we don’t yet handle dynamic casting that involves
>>>>> conditional conformances, and won’t in Swift 4.1.
>>>>>
>>>>> I’d like to take away the "-enable-experimental-conditional-conformances”
>>>>> flag and always allow conditional conformances in Swift 4.1, because the
>>>>> changes in the standard library that make use of conditional conformances
>>>>> can force users to change their code *to themselves use conditional
>>>>> conformances*. Specifically, if they had code like this:
>>>>>
>>>>> extension MutableSlice : P { }
>>>>> extension MutableBidirectionalSlice : P { }
>>>>> // …
>>>>>
>>>>> they’ll get an error about overlapping conformances, and need to do
>>>>> something like the following to fix the issue:
>>>>>
>>>>> extension Slice: P where Base: MutableCollection { }
>>>>>
>>>>> which is way more elegant, but would require passing
>>>>> "-enable-experimental-conditional-conformances”. That seems… unfortunate…
>>>>> given that we’re forcing them to use this feature.
>>>>>
>>>>> My proposal is, specifically:
>>>>>
>>>>> Allow conditional conformances to be used in Swift 4.1 (no flag required)
>>>>> Drop the -enable-experimental-conditional-conformances flag entirely
>>>>> Add a runtime warning when an attempt to dynamic cast fails due to a
>>>>> conditional conformance, so at least users know what’s going on
>>>>>
>>>>
>>>> The last bullet doesn’t feel right to me. It sounds like we would ship a
>>>> feature that we know only partially works, but issue a runtime warning in
>>>> the case we know isn’t fully implemented? I’m I interpretting that point
>>>> correctly?
>>>
>>> Yes, that’s correct. We will fail to match the conformance (i.e., return
>>> “nil” from an “as?” cast), which might be correct and might be wrong.
>>>
>>> - Doug
>>
>> Hmm. I’m concerned that a warning runtime would be to settle. Many people
>> would possibly not even notice it. It’s essentially an edge case in a
>> feature that isn’t fully implemented and thus that part of the feature
>> should not be used yet.
>>
>> What do you think about making this a hard runtime error instead, similar to
>> how we are approaching runtime issues for exclusivity checking? That would
>> be impossible to miss and would convey the optics that this runtime aspect
>> of the feature is not yet supported and thus should not be used.
>
> I’d rather not make it a runtime error, because code that’s doing dynamic
> casting to a protocol is generally already handling the “nil” case (“as?”
> syntax), so aborting the program feels far too strong.
>
> - Doug
For me I think the part I’m struggling with is that making it a warning
conflates two things together: expected failure in the dynamic cast because the
value you are casting doesn’t have that type or — in this case — failure
because the cast can never succeed because it is not supported yet. I feel
like we would be silently swallowing an unsupported condition. If that didn’t
matter, why bother issuing a warning? Clearly were trying to send some kind of
message here about this not being supported.
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
