<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On Dec 27, 2017, at 11:05 AM, Karl Wagner <<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 22. Dec 2017, at 07:13, Ted Kremenek via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 9:39 PM, Ted Kremenek via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> 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 <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> 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 <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> 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 <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> 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 <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> 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 <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>>, 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=""> </div>
</blockquote>
<div class=""><br class=""></div>
<div class="">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?</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. 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.</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? 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. </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. </div><div class=""><br class=""></div><div class=""> - 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. 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 <i class="">some</i> kind of message here about this not being supported.</div></div></div></blockquote><br class=""></div><div class="">Doug and I chatted a bit offline.</div><div class=""><br class=""></div><div class="">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.</div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-dev">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class=""></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">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.</div></blockquote><br><div>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. </div><div><br></div><div>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. </div><div><br></div><div> - Doug</div><div><br></div></body></html>