This draft proposes something that's been discussed on this list several times over the past few years, but now with a different spelling. However, previous objections never centered around the spelling.<br><br>As discussed in previous threads on this topic, any such required keyword breaks retroactive conformance. That is, if I want to conform someone else's type to my protocol, I must edit that person's code if your idea is accepted.<br><br>In so doing, this idea rejects an important (essential, IMO) mental model of what protocol conformance entails. Specifically, I conform a type T to a protocol P when I discover, having already implemented T, that it fulfills the semantic and syntactic requirements of P. Unlike subclassing, I'm not setting out with the intention of making a type T that conforms to P; rather, I discover this fact to my great delight after implementation of T. The analogy to subclassing is therefore inaccurate. Notionally, one always inherits from a superclass first, then overrides.<br><br>This is no mere theoretical notion. It is a Swift idiom to state conformance to protocols in an extension. Sometimes, the type will already implement some but not all of the protocol's requirements outside that extension because it is essential to the raison d'être of the type, and only the balance of the requirements would then be implemented in the extension that states conformance. It would be exceedingly unfortunate to forbid this pattern, which is both elegant and expressive, but OTOH it would be strange to have a method declare that it fulfills a requirement of a protocol to which, lexically, it had not yet been conformed.<br><br>Lastly, it makes a very common task, that of conforming to a protocol, syntactically heavy. This is exacerbated when you consider that the scheme outlined here has the greatest benefit only when conformance to one protocol is concerned. When conforming to more than one protocol, a similar level of compiler help can only be obtained if you allow annotations as to which protocol's requirement is being fulfilled. To implement this additional syntax would be ludicrously heavy, but to ignore the issue would be failing to consider one major aspect of protocols: composability (as opposed to single inheritance). Again here, this is a critical difference from subclassing that makes adapting "override" (regardless of whether you choose a novel spelling) ineffectual.<br><br>Previous discussions on this topic have agreed that the developer experience of conforming a type to a protocol can be greatly improved, but the consensus has been that requiring a keyword to indicate protocol requirements is not the way to go about it. I too would love to see progress made on this issue, but having been previously an advocate for a solution similar to yours, the views of some very wise people have changed my thinking.<br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 17, 2017 at 21:29 David Waite via swift-evolution <<a href="mailto:swift-evolution@swift.org">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" class="gmail_msg"><div class="gmail_msg">I wrote up the following draft proposal around attempting to clarify protocol implementation and protocol extensions, via annotating methods and properties meant to satisfy protocol requirements with additional keywords:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">"Types implementing protocols with optional features (either through default implementations on extensions, or optional methods on objective-C protocols) do not have a way to detect either local typos or later upstream changes to the protocol method signatures will result in behavioral changes. This proposal attempts to rectify that in a manner similar to override on subclassed types."</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I’d appreciate feedback from the list! This is very much a first draft, likely filled with tyops.</div><div class="gmail_msg"><br class="gmail_msg"></div><a href="https://gist.github.com/dwaite/5a10e759a0efd0d9d16e066db4291552" class="gmail_msg" target="_blank">https://gist.github.com/dwaite/5a10e759a0efd0d9d16e066db4291552</a><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-DW</div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>