<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPhone</div><div><br>On 8 May 2017, at 08:44, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On Mon, May 8, 2017 at 2:40 AM, Goffredo Marocchi 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"><div dir="auto"><div>I can understand that, I am just wary of "let's do a partially detrimental change</div></div></blockquote><div><br></div><div>The key here is that there is no detriment to this change. There's no functionality that's being removed, only misleading syntax.</div></div></div></div></div></blockquote><div><br></div><div>Why is it misleading? Because it is not enforced, but protocol extension default methods being shadowable but not overridable and presenting no warning is a very similar issue... if the answer is the same there (at least for classes), I am more than happy to get both changes ;).</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div> no... we will... we will make it proper someday" kind of changes as they seldom work out. Argument labels for stored closures and callbacks are still lost for example :/...</div></div></blockquote><div><br></div><div>That's a totally different issue. Someone needs to write the proposal and implementation for that. </div></div></div></div></div></blockquote><div><br></div><div>Would you and some other be willing to help me (Erica?)? A lot to ask, but it would be important although a bit beyond the scope for "dweller's first proposal" especially the implementation and grammar side. I do not think it has a iota of chance for it to get integrate in time though :/.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div id="m_4551352491754473046AppleMailSignature"></div><div id="m_4551352491754473046AppleMailSignature">Also, while here we keep pushing things Core Team's way, Ted K. is asking for devs' help on swift-dev as there is concern that the currently accepted proposals may not make it with this year's new Swift version (second year in a row). Should we discuss features in scope for Swift 4.1+ only now?</div><div id="m_4551352491754473046AppleMailSignature"><br>Sent from my iPhone</div><div><div class="h5"><div><br>On 8 May 2017, at 08:12, David Hart <<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>> wrote:<br><br></div><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On 8 May 2017, at 09:03, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>> wrote:</div><br class="m_4551352491754473046Apple-interchange-newline"><div><div dir="auto"><div>Over my dead body --random list dweller ;)</div><div><br></div><div>Seriously though, I think the labels should be made to matter not removed if they do not matter now. I think this goes to a path where we should not take protocols as they should be true contracts for the API in question (default method in protocols make me think we have to write unit tests for a protocol which sounds mad... oh well) although some may argue the ownership info is implementation detail and on that point I may agree with you ;).</div></div></div></blockquote><div><br></div><div>Agreed. But we don’t have the time to bring meaning to them in time for Swift 4. Its better to make the language consistent now (disallowing a keyword which currently has no meaning) and allow ourselves to reintroduce later with correct semantics.</div><br><blockquote type="cite"><div><div dir="auto"><div>Sent from my iPhone</div><div><br>On 8 May 2017, at 07:57, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Sounds great! It should be an easy one to get through,<div><br><div><blockquote type="cite"><div>On 8 May 2017, at 08:35, Greg Spiers <<a href="mailto:gspiers@gmail.com" target="_blank">gspiers@gmail.com</a>> wrote:</div><br class="m_4551352491754473046Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 8, 2017 at 6:26 AM, David Hart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="m_4551352491754473046gmail-"><div><br></div><div><br>On 7 May 2017, at 20:12, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div>Today these keywords have no meaning inside a protocol, so clearly it should be an error to use it in that context. I agree with Jordan that the error should be on the protocol.<br><br>It's entirely a different conversation whether the keyword should have meaning or not. If it should, it seems to me it should be limited to protocols that are limited to classes. But that's an additive feature we can discuss later.<br><br>The source-breaking bug fix that is more pressing today is removing meaningless keywords that can be misleading to users, because they have no effect but look like they should.<br></div></blockquote></span></div></blockquote><div>Exactly the trap I fell into when I found this issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="m_4551352491754473046gmail-"><blockquote type="cite"><div></div></blockquote><div><br></div></span><div>Yup, +1. Who wants to write a proposal?</div></div></blockquote><div><br></div><div>I'd like to give it a try. I can write up the proposal to remove the keywords in protocols and will post a draft here for further discussion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="m_4551352491754473046gmail-"><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr">On Sun, May 7, 2017 at 11:00 Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">It would be useful to have a longer discussion on this as... I think that weak has a place there and should be enforced as a protocol is the public facing interface/api for the types who decide to adopt it.<br>
<br>
Sent from my iPhone<br>
<br>
> On 7 May 2017, at 15:41, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> browse<br>
______________________________<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>
</blockquote></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a></span><br></div></blockquote></span></div><br>______________________________<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></blockquote></div><br></div></div>
</div></blockquote></div><br></div></div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div></div></blockquote></div><br></div></blockquote></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>
</div></blockquote></body></html>