<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">I understand the concern.<br />
<br />
To me, the answer is clearly yes. The language cannot be considered in isolation from its use cases; imagine UIKit written in Swift.<br />
<br />
You want the developers to be able to quickly understand which table view delegate methods they need to implement, and what the contract is (are cells editable or non-editable by default?).<br />
<br />
We need the same thing for our own UIKit-style controls we're writing today (and we don't want to be limited to @objc types when doing that — those are particularly ill-suited for the return values of optional delegate methods; I often want a CGFloat? or a enum).<br />
<br />
I don't see this as a separate faculty as much as a shorthand, similar to how T? is a shorthand for Optional<T>.<br />
<br />
The general opinion on shorthands varies from “there should be exactly one way to do everything” Python-style to “the language should help the developer express themselves” Ruby/Perl-style.<br />
<br />
I personally am firmly in the “Ruby camp” here, so I'm all for use case-specific shorthands for general facilities.<br />
<br />
You, sir (together with your dream team), should probably pick an official stance on this matter. :-)<br />
<br />
A.<br /></div>
<div name="trackingimg"><img src="https://img.smartmailcloud.com/dot/7eb55060bd595ad6f602cb5dd7c0e840e165b3581f3a8d431981a554fa1f70d004.gif" width="0" height="0" style="display: block;"/></div><div name="messageSignatureSection"><br /></div>
<div name="messageReplySection"><br />
On 4 Apr 2016 04:15 +0600, Yuval Tal <yuvalt@pblc.co>, wrote:<br />
<blockquote type="cite">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 <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> 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 <<a href="javascript:_e(%7B%7D,'cvml','andrey@tarantsov.com');" target="_blank">andrey@tarantsov.com</a>> 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'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 "more general" 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>
</blockquote>
</div>
</body>
</html>