<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">A quick thing I noticed on a first read (sort of tangential to the rest of the discussion) is that it would be a good idea to land warnings for potential reference cycles sooner rather than later.<div><br></div><div>I have an (un-rebased) branch that lays out what parts of Sema needs to be touched to make this happen and have SR-1807 (<a href="https://bugs.swift.org/browse/SR-1807">https://bugs.swift.org/browse/SR-1807</a>) open for this in general if anybody would like to pick this up and carry it over the goal line. Note that it’s not quite a starter bug.</div><div><br></div><div>Otherwise I’ll allocate time to it later on this winter.<br><br><div id="AppleMailSignature">~Robert Widmann </div><div><br>2017/11/15 2:01、David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>のメール:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 15 Nov 2017, at 03:56, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Having read all the arguments for what to add to local functions it still strikes me as a poor use of engineering resources to fix them (though I do agree they have problems). A better use of resources would be:<div class=""><br class=""></div><div class=""> 1. Deprecate local functions.</div></div></div></blockquote><div><br class=""></div><div>Even if I agreed, which I don’t, I’m fairly sure it’s much too late in Swift’s timeline to deprecate something as huge as local functions.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> 2. Allow closures when assigned to a function type to be:</div><div class=""> 2a. Recursive.</div><div class=""> 2b. Annotatable with:</div><div class=""> 2bi. @inline</div><div class=""> 2bii. @escaping</div><div class=""> 2c. Generic.</div><div class=""><br class=""></div><div class="">That would be a similar engineering effort and give a better short term result of better closures which would be much more widely applicable as well as addressing the issues with local functions.</div><div class=""><br class=""></div><div class="">It also gives a better long term result of not having to maintain local functions.</div><div class=""> </div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br class=""></div></div>
<br class=""><div class="gmail_quote">On 15 November 2017 at 09:08, Alex Lynch via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">The inference algebra just suggested was enjoyable to read, but is still a new syntax. Which is interesting and deserving of its own proposal. The purpose of this proposal is simply to introduce the existing capture syntax to local functions. Thanks to everyone's feedback pointing out that the `self` reference analysis is a deeper question than initially realized. <div class=""><br class=""></div><div class="">Alex</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="h5">On Tue, Nov 14, 2017 at 4:36 PM, Mike Kluev via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="h5"><div dir="ltr" class=""><span class="">On 14 November 2017 at 21:02, David Hart <span dir="ltr" class=""><<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>></span> wrote:<br class=""></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><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 style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><span class="m_6043367993829337200m_-5026886634801406416gmail-"><div class=""><br class=""></div></span>I’d be very hesitant to introduce this syntax:</div><div class=""><br class=""></div><div class=""><ul class="m_6043367993829337200m_-5026886634801406416gmail-m_2863118398544756606MailOutline"><li class="">it’s new syntax, so it comes with a complexity tax (it isn’t naturally obvious what it means for a func to be weak)</li><li class="">it’s only sugar for the capture of self</li></ul></div></div></blockquote></span><div class="">it might cover well over 90% of use cases (by my "pessimistic" estimate)... if someone has a quick way to scan and analyse, say, github swift sources we may even know that current percentage number of real life usage.</div><span class=""><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 style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><ul class="m_6043367993829337200m_-5026886634801406416gmail-m_2863118398544756606MailOutline"><li class="">it doesn’t transpose well to local closures</li></ul></div></div></blockquote><div class=""><br class=""></div></span><div class="">the last one - maybe not. follow me:</div><div class=""><br class=""></div><div class="">let closure = { [weak self, bar] in ... }</div><div class=""><br class=""></div><div class="">which today can be written as: <br class=""></div><div class=""><br class=""></div><div class="">let closure = { [weak self, bar] () -> Int in ... } // full form</div><div class=""><br class=""></div><div class="">or as:</div><div class=""><br class=""></div><div class=""><div class="">let closure: () -> Int = { [weak self, bar] in ... } // full form</div></div><div class=""><br class=""></div><div class=""><div class="">which allows this change:<br class=""></div></div><div class=""><br class=""></div><div class="">let closure: [weak self, bar] () -> Int = { ... } // full alt form</div><div class=""><br class=""></div><div class="">or in alternative form:</div><div class=""><br class=""></div><div class=""><div class="">let closure: weak () -> Int = { [bar] in ... } // short hand form</div></div><div class=""><br class=""></div><div class="">same can be with functions:</div><div class=""><br class=""></div><div class="">func fn() -> Int { [weak self, bar] in ... } // full form</div><div class=""><br class=""></div><div class="">weak func fn() -> Int { [bar] in ... } // short hand form</div><div class=""><br class=""></div><div class="">the two capture attributes will in practice be "close" to each other:</div><div class=""><br class=""></div><div class=""><div class="">weak func fn() {</div><div class=""> [bar] in</div><div class=""> ....</div><div class="">}</div></div><div class=""><br class=""></div><div class="">and in majority of cases there will be only weak self:</div><div class=""><br class=""></div><div class=""><div class="">weak func fn() {</div><div class=""> ....<br class=""></div><div class="">}</div></div><div class=""><br class=""></div><div class="">Mike</div><div class=""><br class=""></div></div></div></div>
<br class=""></div></div><span class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></span></blockquote></div><br class=""></div>
<br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></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></div></body></html>