[swift-dev] Conditional conformance: Removing the opt-in flag

[Dave Abrahams]

> On Dec 18, 2017, at 4:52 PM, Douglas Gregor via swift-dev <swift-dev at 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
> 
> Thoughts?

I'm confused; I thought that overlapping conformances could result in cases where it's ambiguous which extension to use to satisfy a requirement, but I don't see anything in your proposal for handling that.  Does that become a dynamic failure?

-Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171218/4d14d248/attachment.html>