> On 22. Dec 2017, at 07:13, Ted Kremenek via swift-dev <swift-dev@swift.org>
> wrote:
>
>
>
>> On Dec 19, 2017, at 9:39 PM, Ted Kremenek via swift-dev <swift-dev@swift.org
>> <mailto: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
What about if we disabled conditional conformances for non-generic protocols
(or keep that part behind the flag)? It seems a bit arbitrary, but IIRC, the
standard library uses conditional conformances for things like Equatable and
the various faces of Collection, which are not runtime-castable anyway.
- Karl
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
