<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On 14 Jun 2017, at 21:41, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Wed, Jun 14, 2017 at 3:37 PM, Vladimir.S via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</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">On 14.06.2017 21:23, Haravikk via swift-evolution wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<span><br>
<br>
On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.<wbr>org</a>>> wrote:<br>
<br>
Sorry, initially sent off-list:<br>
<br>
I think this proposal is a great idea. But I would vote for the alternative of<br>
only having default and implicitly deducing extend when default is not specified:<br>
<br>
<br>
This wouldn't work with the fundamental design decision that these are optional keywords, which IMO is absolutely key.<br>
</span></blockquote><span>
<br>
Hmm, I'm inclined to agree with David that only the default keyword really seems like it's necessary, and that extend can be implied.<br>
<br>
</span></blockquote>
<br>
I'm not so sure. If they are optional, then it depends on developer if he/she wants to explicitly mark some func to avoid possible errors. Please look here :<br>
<br>
1. First we have this<br>
<br>
protocol A {<br>
func foo() {}<br>
}<br>
<br>
and we write extension (possible in another file)<br>
<br>
extension A {<br>
extent func bar() {} // I'm sure currently I want *additional* 'bar' method<br>
}<br>
<br>
2. Then 'A' protocol has been changed for some reason :<br>
<br>
protocol A {<br>
func foo() {}<br>
func bar() {}<br>
}<br>
<br>
Now, if we have 'extent' - we(compiler) can detect the problem here('bar' was not the default implementation for A's requirement). Without 'extent' - 'bar' will be default implementation without our intent for this.<br>
<br>
So, in case suggested keywords are both optional - IMO we need both.<br>
In case 'default' is required - then yes, we need only it.<br></blockquote><div><br></div><div>Yes, I think we are all in vigorous agreement about this. The question is whether, at this point in Swift's evolution, a wide-ranging migration due to a new required keyword will be well tolerated. If not, then the solution is constrained.</div><div><br></div></div></div></div></div></blockquote><div><br></div><div>I personally vote to accept such a migration at this point, but I am not sure how others feel.</div><br><blockquote type="cite"><div><div dir="ltr"><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">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
My preference would be to just add the default keyword, and have breaches treated as warnings using the current behaviour, which we can eliminate and elevate to an error in future once people have had a chance to change their code.<br>
<br>
<br></span><span>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br>
</span></blockquote><div class="m_-1838139386318633016HOEnZb"><div class="m_-1838139386318633016h5">
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>