That&#39;s a good point. Since you&#39;re proposing an optional keyword, though, aren&#39;t you describing a linter functionality?<br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 22, 2016 at 18:25 Charles Srstka &lt;<a href="mailto:cocoadev@charlessoft.com">cocoadev@charlessoft.com</a>&gt; 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"><blockquote type="cite">On Aug 22, 2016, at 5:41 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br></blockquote></div><div style="word-wrap:break-word"><div><blockquote type="cite"><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">There&#39;s been agreement even from the core team that the quality of diagnostics when conforming to a protocol is sub-par.</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">The modified rule you propose has also been suggested before. The reason it doesn&#39;t help is that (1) if a method signature is mismatched accidentally due to a typo, you get a compilation error already because your type doesn&#39;t conform to the protocol (it&#39;s the quality of the error message that needs improvement);</span></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>You don’t get any error at all if there’s a default value.</div><div><br></div><div>protocol P {</div><div><span style="white-space:pre-wrap">        </span>func doSomething()</div><div>}</div><div><br></div><div>extension P {</div><div><span style="white-space:pre-wrap">        </span>func doSomething() { print(“Do This Thing”) }</div><div>}</div><div><br></div><div>struct S: P {</div><div><span style="white-space:pre-wrap">        </span>func doSomthing() { print(“Do This Instead”) } // Whoops, doesn’t get called. And we don’t find out until mysterious behavior occurs at runtime.</div><div>}</div><div><br></div><div>If there were a way to tell the compiler that the function was meant to satisfy a protocol, we could prevent the mistake above from occurring.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> (2) otherwise, if your type fulfills all protocol requirements but also implements an additional method unnecessary for conformance, what is the harm that is being prevented by a compiler error?</span></div></blockquote></div></div><div style="word-wrap:break-word"><div></div><br><div>The fact that implementing protocol requirements that have default values is, in effect, stringly typed.</div></div><div style="word-wrap:break-word"><div><br></div><div>Charles</div><div><br></div></div></blockquote></div>