<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period.<div class=""><br class=""></div><div class="">Thanks for the work on the proposal!!<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 16 Jun 2017, at 16:33, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">As we say in our introduction, we're pitching the most conservative approach.&nbsp;</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code bases.</div></blockquote><div class=""><br class=""></div><div class="">We discuss the one keyword version (which most of us are a fan of) in the alternatives. The core team has to decide how much they're willing to allow existing code to warn and/or break, which is the consequence of the one keyword solution.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jun 16, 2017, at 7:44 AM, David Hart &lt;<a href="mailto:davidhart@fastmail.com" class="">davidhart@fastmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters.<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Wed Jun 14 2017, Chris Lattner &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution<br class="">&lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class="">Some pals and I have been kicking an idea around about introducing<br class="">better ways to support the compiler in protocol extensions. We want<br class=""></blockquote><br class=""><blockquote type="cite" class="">to eliminate some hard-to-detect bugs. We've been brainstorming on<br class="">how to do this without affecting backward compatibility and<br class="">introducing a minimal impact on keywords.<br class=""><br class="">We'd love to know what you think of our idea, which is to introduce<br class="">"role" keywords. Roles allow the compiler to automatically check the<br class="">intended use of a extension member definition against its protocol<br class="">declarations, and emit errors, warnings, and fixits as needed. &nbsp;We<br class="">think it's a pretty straightforward approach that, if adopted,<br class="">eliminates an entire category of bugs.<br class=""><br class="">The draft proposal is here:<br class=""><a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" class="">https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4</a><br class="">&lt;<a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" class="">https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4</a>&gt;<br class=""><br class="">Thanks in advance for your thoughtful feedback,<br class=""></blockquote><br class="">+1 on the idea of this. &nbsp;<br class=""></blockquote><br class="">ditto. &nbsp;IMO it also makes the protocol extension much more expressive<br class="">and easy to read.<br class=""><br class="">-- <br class="">-Dave<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">Pull request:&nbsp;<a href="https://github.com/apple/swift-evolution/pull/724" class="">https://github.com/apple/swift-evolution/pull/724</a></div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>