<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 9:39 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Dec 19, 2017, at 8:57 PM, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><br class=""><br class=""><div class="">Sent from my iPhone</div><div class=""><br class="">On Dec 19, 2017, at 8:31 PM, Ted Kremenek &lt;<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Dec 19, 2017, at 3:59 PM, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><br class=""><div class=""><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 class="">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 class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div></div></blockquote><br class=""><div class="">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 class=""><br class=""></div><div class="">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></div></blockquote><br class=""><div class="">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.&nbsp;</div><div class=""><br class=""></div><div class="">&nbsp; - Doug</div></div></blockquote><br class=""><div class="">For me I think the part I’m struggling with is that making it a warning conflates two things together: <i class="">expected</i> 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 <i class="">never</i> succeed because it is not supported yet. &nbsp;I feel like we would be silently swallowing an unsupported condition. &nbsp;If that didn’t matter, why bother issuing a warning? &nbsp;Clearly were trying to send <i class="">some</i> kind of message here about this not being supported.</div></div></div></blockquote><br class=""></div><div>Doug and I chatted a bit offline.</div><div><br class=""></div><div>I’m now more on the side of thinking a warning is a reasonable approach. &nbsp;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”. &nbsp;That said, I think the cases impacted here are likely very, very small — and a crash in the program is probably excessive.</div></body></html>