<div dir="ltr">On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <span dir="ltr"><<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Sorry, initially sent off-list:<div><br></div><div><div><span style="background-color:rgba(255,255,255,0)">I think this proposal is a great idea. But I would vote for the alternative of only having default and implicitly deducing extend when default is not specified:</span></div></div></div></blockquote><div><br></div></span><div>This wouldn't work with the fundamental design decision that these are optional keywords, which IMO is absolutely key.</div></div></div></div></blockquote><div> </div><div>...I may need to take this back; the design has annotations on the default and not on the overriding functions, which means there should be no negative impact on retroactive conformance (unless I'm mistaken). In that case, it might not need to be optional, and then reducing two keywords to one might be a nice idea...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><span style="background-color:rgba(255,255,255,0)"> it would mimic how override works with only one keyword, it would not introduce a completely new keyword, and it would provide progressive disclosure (your usually start implementing types before going deeper in default implementations). Yes, it would generate warnings at all current default implementations, but it wouldn’t break source compatibility and would provide a lot of value for developers.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">Perhaps a future version of Swift could transform that warning into an error to provide the most value and really mirror the override behavior.</span></div><div><div class="m_-1893855947277184918h5"><div><br>On 14 Jun 2017, at 19:11, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Some pals and I have been kicking an idea around about introducing better ways to support the compiler in protocol extensions. We want to eliminate some hard-to-detect bugs. We've been brainstorming on how to do this without affecting backward compatibility and introducing a minimal impact on keywords. <div><br></div><div>We'd love to know what you think of our idea, which is to introduce "role" keywords. Roles allow the compiler to automatically check the intended use of a extension member definition against its protocol declarations, and emit errors, warnings, and fixits as needed. We think it's a pretty straightforward approach that, if adopted, eliminates an entire category of bugs.</div><div><br></div><div>The draft proposal is here: <a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" target="_blank">https://gist.github.com/<wbr>erica/14283fe18254489c1498a706<wbr>9b7760c4</a></div><div><br></div><div>Thanks in advance for your thoughtful feedback,</div><div><br></div><div><div><div>-- E</div></div></div><div><br></div></div></blockquote></div></div><span><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></span><br></div></blockquote></span></div></div><br>______________________________<wbr>_________________<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/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>