For readability and specifically in this case, I think it does make sense IMHO. <span></span><br><br>On Sunday, April 3, 2016, Chris Lattner &lt;<a href="mailto:clattner@apple.com">clattner@apple.com</a>&gt; 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"><br><div><blockquote type="cite"><div>On Apr 3, 2016, at 10:40 AM, Andrey Tarantsov &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;andrey@tarantsov.com&#39;);" target="_blank">andrey@tarantsov.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div 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"><div>Protocol requirements with default (no-op) implementations already satisfy that design goal, no?</div></div></div></blockquote><br></div><div>Chris, as we&#39;ve discussed in a thread that I think got forked from this one:</div><div><br></div><div>Yes, they do technically, but it would be nice to both:</div><div><br></div><div>1) make it an obvious documented part of the signature, possibly including the default return value</div><div><br></div><div>2) possibly make it less verbose by getting rid of the explicitly spelled out protocol extension</div></div></div></blockquote><br></div><div>Right, but “more is worse” when it comes to language design.  Having a &quot;more general&quot; facility that greatly overlaps with a “more narrow” facility always makes us question whether it is worth the complexity to have both.</div><div><br></div><div>-Chris</div><br></div></blockquote>