<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Dec 19, 2017, at 3:59 PM, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 2:26 PM, Ted Kremenek via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">

<title class=""></title>

<div class="">
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class=""><br class="">
On Dec 18, 2017, 4:53 PM -0800, Douglas Gregor via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt;, wrote:<br class="">
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;" class="">Hi all,
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">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:</div>
<div class=""><br class=""></div>
<blockquote style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;" class="">
<div class=""><font face="Menlo" class="">extension MutableSlice : P { }</font></div>
<div class=""><font face="Menlo" class="">extension MutableBidirectionalSlice : P { }</font></div>
<div class=""><font face="Menlo" class="">// …</font></div>
</blockquote>
<div class=""><br class=""></div>
<div class="">they’ll get an error about overlapping conformances, and need to do something like the following to fix the issue:</div>
<div class=""><br class=""></div>
<blockquote style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;" class="">
<div class=""><font face="Menlo" class="">extension Slice: P where Base: MutableCollection { }</font></div>
</blockquote>
<div class=""><br class=""></div>
<div class="">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.</div>
<div class=""><br class=""></div>
<div class="">My proposal is, specifically:</div>
<div class=""><br class=""></div>
<div class="">
<ul class="MailOutline">
<li class="">Allow conditional conformances to be used in Swift 4.1 (no flag required)</li>
<li class="">Drop the -enable-experimental-conditional-conformances flag entirely</li>
<li class="">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</li>
</ul>
</div>
<div class="">&nbsp;</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">The last bullet doesn’t feel right to me. &nbsp;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? &nbsp;I’m I interpretting that point correctly?</div>
</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div></div></blockquote><br><div>Hmm. &nbsp;I’m concerned that a warning runtime would be to settle. Many people would possibly not even notice it. &nbsp;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.</div><div><br></div><div>What do you think about making this a hard runtime error instead, similar to how we are approaching runtime issues for exclusivity checking? &nbsp;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.&nbsp;</div></body></html>