<div dir="ltr">On Sat, Feb 18, 2017 at 1:07 AM, David Waite <span dir="ltr"><<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.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"><span class=""><br>
> On Feb 17, 2017, at 10:53 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> 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>
</span>I believe this proposal is different in that it only requires specification for clarity not for behavioral changes, and only requires the keyword to be specified for protocols known at the site of method/property declaration.<br></blockquote><div><br></div><div>If indeed you frame your proposal in this way, a best effort to add clarity of intention, my feedback is that there are ways to gain the same (or at least, very similar) benefits without being source-breaking, and indeed without introducing new keywords at all.</div><div><br></div><div>For example:</div><div>- Doc comments are parsed. We already have `- Parameter` in doc comments, which improved tooling could double-check to ensure that the stuff we put there matches the stuff in the function signature (hmm, that'd be a nice additive proposal, right?).<br></div><div>- The same tool could be augmented to recognize a spelling such as `- RequiredBy:`, and you could list the specific protocols that require the method. Then, you would be warned at compiled time if your method is in fact not required by a protocol. This design has the side benefit of telling the reader of your code exactly what protocols require that method, not just that it's required by some protocol.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">><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>
</span>The declaration is only required on types for protocols which the type is known to implement at the file level. If some other code (even within the same module) extends a type to support a protocol, there is no requirement that previous methods had been documented as fulfilling that new protocol.<br>
<br>
In this sense, not every method which is mapped into a protocol may be marked as fulfilling a protocol, but the purpose isn’t to solve every corner case. If that were indeed the purpose, I could propose something much wordier where the extension has to declare that intent to expose existing methods as part of protocol conformance.<br>
<span class=""><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>
</span>The purpose isn’t to map methods to protocols, but to clarify that a method exists to meet the requirements of a protocol. Without this, a simple typo (or redefinition of methods such as with the changes in Swift 3’s importer) causes what you thought was conforming to a protocol to either fail, or worse silently change behavior.</blockquote><div><br></div><div>As I demonstrate above, there are other designs possible that do not require source breakage, or even any new keywords, which recover essentially all of the benefits you list here. Such alternative designs would be opt-in, so those who care about this additional compiler help can use it, and those who do not won't need to, consistent with Swift's new emphasis on compatibility and its established emphasis on progressive disclosure.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 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>
<br>
</span>There are often cases for the compiler to guess a developer’s intent to simplify syntax, but in this case I believe people are being bit by the compiler guessing incorrectly. If protocols didn’t make implementation of its requirements optional (via optional methods in objective-c, and protocol extensions in Swift) then there wouldn’t be a need to annotate methods to clarify intent. Given those features, I have trouble imagining a system where a compiler would be able to understand the developer’s intent and prevent issues without tagging protocol implementations in some manner.<br>
<br>
Unless I’m incorrect in my assumption that there compiler could only infer developer intent via some sort of method tagging, then it really is a decision whether clarity or terseness is more important in this scenario.<br>
<span class="HOEnZb"><font color="#888888"><br>
-DW<br>
<br>
</font></span></blockquote></div><br></div></div>