<div dir="ltr">You can add generic closures with some name mangling and simple transformations, nothing very hard.<div><br></div><div>The compiler can emit the following for example:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">// User writes<br>let increment: &lt;T: Numeric&gt;(T) -&gt; T = { $0 + 1 }<br>increment(1) // 2<br>increment(1.1) // 2.1<br><br><br>// Compiler issues<br>struct _Generic_Increment&lt;T: Numeric&gt; { // Mangle name<br>    let increment: (T) -&gt; T = { $0 + 1 }<br>}<br>_Generic_Increment&lt;Int&gt;().increment(1) // 2<br>_Generic_Increment&lt;Double&gt;().increment(1.1) // 2.1<br></blockquote><br><div>It&#39;s plausible that the compiler can do better than the above, but the above would be sufficient and is easy to do.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">  -- Howard.<br></div></div>
<br><div class="gmail_quote">On 15 November 2017 at 14:02, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><br><div id="m_261741036942948137AppleMailSignature">Sent from my iPhone</div><div><br>On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">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><br></div><div>  1. Deprecate local functions.</div><div>  2. Allow closures when assigned to a function type to be:</div><div>      2a. Recursive.</div><div>      2b. Annotatable with:</div><div>            2bi.  @inline</div><div>            2bii. @escaping</div><div>      2c. Generic.</div><div><br></div><div>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></div></blockquote><div><br></div>I believe generic closures would require adding higher rank types to Swift.  That would be pretty cool but I suspect the engineering effort is at least an order of magnitude greater than the changes discussed in this thread.<div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>It also gives a better long term result of not having to maintain local functions.</div><div>  </div></div><div class="gmail_extra"><br clear="all"><div><div class="m_261741036942948137gmail_signature" data-smartmail="gmail_signature">  -- Howard.<br></div></div>
<br><div class="gmail_quote">On 15 November 2017 at 09:08, Alex Lynch via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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&#39;s feedback pointing out that the `self` reference analysis is a deeper question than initially realized. <div><br></div><div>Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_261741036942948137h5">On Tue, Nov 14, 2017 at 4:36 PM, Mike Kluev via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_261741036942948137h5"><div dir="ltr"><span>On 14 November 2017 at 21:02, David Hart <span dir="ltr">&lt;<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>&gt;</span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><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"><br><div><span class="m_261741036942948137m_6043367993829337200m_-5026886634801406416gmail-"><div><br></div></span>I’d be very hesitant to introduce this syntax:</div><div><br></div><div><ul class="m_261741036942948137m_6043367993829337200m_-5026886634801406416gmail-m_2863118398544756606MailOutline"><li>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>it’s only sugar for the capture of self</li></ul></div></div></blockquote></span><div>it might cover well over 90% of use cases (by my &quot;pessimistic&quot; 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><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"><div><ul class="m_261741036942948137m_6043367993829337200m_-5026886634801406416gmail-m_2863118398544756606MailOutline"><li>it doesn’t transpose well to local closures</li></ul></div></div></blockquote><div><br></div></span><div>the last one - maybe not. follow me:</div><div><br></div><div>let closure = { [weak self, bar] in ... }</div><div><br></div><div>which today can be written as: <br></div><div><br></div><div>let closure = { [weak self, bar] () -&gt; Int in ... } // full form</div><div><br></div><div>or as:</div><div><br></div><div><div>let closure: () -&gt; Int = { [weak self, bar] in ... } // full form</div></div><div><br></div><div><div>which allows this change:<br></div></div><div><br></div><div>let closure:  [weak self, bar] () -&gt; Int = { ... } // full alt form</div><div><br></div><div>or in alternative form:</div><div><br></div><div><div>let closure:  weak () -&gt; Int = { [bar] in ... } // short hand form</div></div><div><br></div><div>same can be with functions:</div><div><br></div><div>func fn() -&gt; Int { [weak self, bar] in ... } // full form</div><div><br></div><div>weak func fn() -&gt; Int { [bar] in ... } // short hand form</div><div><br></div><div>the two capture attributes will in practice be &quot;close&quot; to each other:</div><div><br></div><div><div>weak func fn() {</div><div>    [bar] in</div><div>    ....</div><div>}</div></div><div><br></div><div>and in majority of cases there will be only weak self:</div><div><br></div><div><div>weak func fn() {</div><div>    ....<br></div><div>}</div></div><div><br></div><div>Mike</div><div><br></div></div></div></div>
<br></div></div><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><br></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></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>