Sent from my iPhone
> On Dec 19, 2017, at 8:31 PM, Ted Kremenek <kreme...@apple.com> wrote:
>
>
>
>> 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.
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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
