> On Dec 19, 2017, at 9:39 PM, Ted Kremenek via swift-dev <swift-dev@swift.org>
> wrote:
>
>
>
> On Dec 19, 2017, at 8:57 PM, Douglas Gregor <dgre...@apple.com
> <mailto:dgre...@apple.com>> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kreme...@apple.com
>> <mailto:kreme...@apple.com>> wrote:
>>
>>>
>>>
>>> On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgre...@apple.com
>>> <mailto:dgre...@apple.com>> wrote:
>>>
>>>>
>>>>
>>>>> On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev
>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>>>>
>>>>>
>>>>> On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev
>>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>>, 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.
Doug and I chatted a bit offline.
I’m now more on the side of thinking a warning is a reasonable approach. I’m
still concerned that it will be unnoticed by some developers, and I am mixed on
conflating failure the cast of “this doesn’t work at all for this specific type
because it has a conditional conformance” versus “this didn’t work because the
type didn’t conform to the protocol”. That said, I think the cases impacted
here are likely very, very small — and a crash in the program is probably
excessive.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
