<div><br><div class="gmail_quote"><div>On Fri, Jun 16, 2017 at 14:42 Paul Cantrell <<a href="mailto:cantrell@pobox.com">cantrell@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jun 16, 2017, at 2:26 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-3570691301024079132Apple-interchange-newline"><div><div><div><div class="gmail_quote"><div>On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3570691301024079132m_1230042748382363970m_4509709503744220765Apple-interchange-newline"><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><div><div>On Jun 16, 2017, at 8:44 AM, David Hart <<a href="mailto:davidhart@fastmail.com" target="_blank">davidhart@fastmail.com</a>> wrote:</div><br class="m_-3570691301024079132m_1230042748382363970m_4509709503744220765Apple-interchange-newline"><div><div style="word-wrap:break-word">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><br></div><div>Thanks for the work on the proposal!!<br></div></div></div></div></div></blockquote></div><div><div style="word-wrap:break-word"><div><div><div style="word-wrap:break-word"><div><br></div></div></div></div></div></div><div>I believe a breaking change has little chance of being accepted at this point in the language lifecycle. Adding opt-in compiler auditing to increase safety is, IMO, a net positive. It's a deliberate trade-off. We have included other designs to allow the core team to choose an alternative they feel is best for the philosophy and direction of Swift. This doesn't close the door to future language releases enhancing the concept, phasing out the second keyword, or introducing keywords for additional safety auditing.</div><div><br></div><div>I find it a dangerous philosophy to insist that any new proposal be ideologically pure. Imperfect proposals can still improve the language within the realities of the timelines, user base, and code base of the Swift community.</div></div></div></blockquote><div><blockquote type="cite"><br></blockquote></div><div><blockquote type="cite"><div style="word-wrap:break-word"><div>-- E</div></div></blockquote><div><div style="word-wrap:break-word"><div><br></div></div></div></div></div></div></div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><div>I share David’s concern. I also tend to think Erica’s correct about breaking changes. If the core team says “go ahead and break it,” then I’m all for it, but that seems unlikely.</div><div><br></div><div>FWIW, if we’re sticking with the two-keyword approach, the language could emit warnings for _any_ extension members that aren’t marked with either `extend` or `default`.</div></div></div></div></blockquote><div><br></div></div></div></div><div><div><div class="gmail_quote"><div>If the language were to do that, then it would certainly be superior to use the one-keyword approach, since this is equal breakage with an extra keyword.</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I wouldn’t consider new warnings to be “breakage.” Warnings offer a gentler migration path than non-compilation.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div><br></div><div>Unfortunately, the single keyword approach wouldn’t support warnings the same way.</div></div></div></blockquote><div><br></div><div>No, but even that could offer benefits, and if transitional it would phase in the benefits while phasing in the change.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div> So it’s really a question of what the tolerance for breakage is among the core team.</div></div></div><div style="word-wrap:break-word"><div></div></div></blockquote><div><br></div><div>Indeed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div><div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><div></div></div></div></div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><div><br></div><div>P</div></div></div></div><div style="word-wrap:break-word"><div style="word-wrap:break-word"><div><div><br></div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br></div><div><blockquote type="cite"><div><br></div><div><div style="word-wrap:break-word"><div><div><div><blockquote type="cite"><div>On 16 Jun 2017, at 16:33, Erica Sadun <<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>> wrote:</div><br class="m_-3570691301024079132m_1230042748382363970m_4509709503744220765Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>As we say in our introduction, we're pitching the most conservative approach. </div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>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><br></div><div>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><br></div><div>-- E</div><div><br></div><div><blockquote type="cite"><div>On Jun 16, 2017, at 7:44 AM, David Hart <<a href="mailto:davidhart@fastmail.com" target="_blank">davidhart@fastmail.com</a>> wrote:</div><br class="m_-3570691301024079132m_1230042748382363970m_4509709503744220765Apple-interchange-newline"><div><div style="word-wrap:break-word">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><br><div><blockquote type="cite"><div>On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3570691301024079132m_1230042748382363970m_4509709503744220765Apple-interchange-newline"><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-3570691301024079132m_1230042748382363970m_4509709503744220765Apple-interchange-newline"><div><div><br>on Wed Jun 14 2017, Chris Lattner <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br><blockquote type="cite"><blockquote type="cite">On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution<br><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br>Some pals and I have been kicking an idea around about introducing<br>better ways to support the compiler in protocol extensions. We want<br></blockquote><br><blockquote type="cite">to eliminate some hard-to-detect bugs. We've been brainstorming on<br>how to do this without affecting backward compatibility and<br>introducing a minimal impact on keywords.<br><br>We'd love to know what you think of our idea, which is to introduce<br>"role" keywords. Roles allow the compiler to automatically check the<br>intended use of a extension member definition against its protocol<br>declarations, and emit errors, warnings, and fixits as needed. We<br>think it's a pretty straightforward approach that, if adopted,<br>eliminates an entire category of bugs.<br><br>The draft proposal is here:<br><a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" target="_blank">https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4</a><br><<a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" target="_blank">https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4</a>><br><br>Thanks in advance for your thoughtful feedback,<br></blockquote><br>+1 on the idea of this. <br></blockquote><br>ditto. IMO it also makes the protocol extension much more expressive<br>and easy to read.<br><br>-- <br>-Dave<br></div></div></blockquote></div><br><div><br></div><div>Pull request: <a href="https://github.com/apple/swift-evolution/pull/724" target="_blank">https://github.com/apple/swift-evolution/pull/724</a></div><div><br></div><div>-- E</div><div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>
</div></blockquote></div></div></blockquote></div></div>