<div dir="ltr">I like that this is minimal impact because it is optional. Since it is optional, I wonder if making it visually distinct from the mandatory keywords such as "override" for classes would be optimal, perhaps by making these @annotations.<div><br></div><div>Otherwise the naming is near perfect, IMO. It follows by analogy with `override` and `convenience`. There is one nit here that `override func` reads well in two senses: it's an overriding function with a certain signature _and_ it's overriding a function with that signature. Moreover, "override" can be read as a noun (a nouned verb, but plausibly a noun nonetheless), fitting in better with "convenience" and "default." By contrast, an `extend func` would be an extending function _but_ it's not extending a function, so it may read more awkwardly. It's also definitely not a noun. Might it be possible simply to reuse the keyword `extension` in this context?</div><div><br></div><div>As to the overall design, I like this much better than all previous alternatives, which are amply discussed in your proposal text.</div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 14, 2017 at 12:11 PM, Erica Sadun via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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/<wbr>14283fe18254489c1498a7069b7760<wbr>c4</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><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div></div>