> On Dec 19, 2017, at 3:59 PM, Douglas Gregor <dgre...@apple.com> wrote:
>
>
>
>> On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev
>> <swift-dev@swift.org> wrote:
>>
>>
>>> On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev
>>> <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.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
