<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=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 14 Jun 2017, at 20:19, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</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; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span> wrote:<br class=""><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" class=""><span class="">On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></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" class="">Sorry, initially sent off-list:<div class=""><br class=""></div><div class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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 class=""><br class=""></div></span><div class="">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 class=""> </div><div class="">...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></div></div></div></blockquote><div class=""><br class=""></div><div class="">Making them optional is critical for source stability. I think David’s suggestion is a better overall design but I’m not sure it will fly. It would require a migrator to add `default` to all default implementations in protocol extensions in existing code. The window for changes like that may have already passed.</div></div></div></div></blockquote><div><br class=""></div><div>The Swift 4 compiler in -swift-version 3 modes generates extra warnings: as long as it compiles, it is still source-compatible.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><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" class=""><div class=""><div class=""><span style="background-color:rgba(255,255,255,0)" class=""> 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 class=""><span style="background-color:rgba(255,255,255,0)" class=""><br class=""></span></div><div class=""><span style="background-color:rgba(255,255,255,0)" class="">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 class=""><div class="m_-1893855947277184918h5"><div class=""><br class="">On 14 Jun 2017, at 19:11, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">The draft proposal is here: <a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" target="_blank" class="">https://gist.github.com/<wbr class="">erica/14283fe18254489c1498a706<wbr class="">9b7760c4</a></div><div class=""><br class=""></div><div class="">Thanks in advance for your thoughtful feedback,</div><div class=""><br class=""></div><div class=""><div class=""><div class="">-- E</div></div></div><div class=""><br class=""></div></div></blockquote></div></div><span class=""><blockquote type="cite" class=""><div class=""><span class="">______________________________<wbr class="">_________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a></span><br class=""></div></blockquote></span></div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></span></div><br class=""></div></div>
</blockquote></div><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></blockquote></div><br class=""></body></html>