> On Jan 2, 2018, at 11:14 AM, Itai Ferber <[email protected]> wrote:
>
> On 27 Dec 2017, at 12:41, Douglas Gregor via swift-dev wrote:
>
>
>
> Sent from my iPhone
>
> On Dec 27, 2017, at 11:05 AM, Karl Wagner <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>
>>> On 22. Dec 2017, at 07:13, Ted Kremenek via swift-dev <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>
>>>> On Dec 19, 2017, at 9:39 PM, Ted Kremenek via swift-dev
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>
>>>> On Dec 19, 2017, at 8:57 PM, Douglas Gregor <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Dec 19, 2017, at 8:31 PM, Ted Kremenek <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Dec 19, 2017, at 3:59 PM, Douglas Gregor <[email protected]
>>>>>> <mailto:[email protected]>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev
>>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev
>>>>>>>> <[email protected] <mailto:[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.
>>>
>>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>> <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.
>
> This is a reasonable approach. To make it consistent, we would want to make
> the Codable conformances of Array, Set, Dictionary, and Optional
> unconditional again—otherwise, user code couldn’t have Codable conformances
> for some types without adding the flag.
>
> I’m hesitant to do this because the unconditional conformances to Codable are
> wrong, and fixing them is going to cause some (legitimate, necessary) source
> breakage. It feels better overall to get that out of the way sooner... before
> more wrong Codable conformances get layered on top.
>
> - Doug
>
> Just to be clear, what is the current impact of leaving those Codable
> conformances conditional? Having casts like [1,2,3] as? Codable fail?
>
Right. Those casts, which would have succeeded in Swift 4, will fail (with a
runtime warning) in Swift 4.1.
> For what it’s worth, I’m not entirely certain how useful type-erased
> Encodable and Decodable values are in practice (aside from the very
> workarounds we used because conditional conformances weren’t ready yet)…
>
The standard library had a bunch of clever trickery to deal with type-erased
Encodable and Decodable… I suspect few others did the same thing.
> Can we try to get some metrics about whether people do this at all today and
> for what purposes?
>
Unfortunately, I don’t know of a good way to do that.
> I don’t feel too strongly either way (these conformances have been
> unconditional so far, so we’re not regressing anything by not doing this for
> Codable), but I do think it would be nice to have the actual conditional
> conformances in place if we’re not breaking anyone.
>
Yes, I agree. I especially want to get the source-breakage aspect out of the
way.
- Doug
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
