<div dir="ltr">I should qualify that I am not proposing removing local functions without replacing them with closures that have the same power. I don&#39;t believe powerful closures are something the compiler couldn&#39;t do, in fact I believe it is something that is relatively easy. I believe this because there isn&#39;t much difference between a function and a closure and because the function behaviour is easy to fake and therefore something the compiler could do (in fact do better than you can fake). Two of the example presented of things closures can&#39;t do are mutual recursion and generics, both are fakable:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>var isEven: ((UInt) -&gt; Bool)! = nil // Forward declaration!</div><div>var isOdd: ((UInt) -&gt; Bool)! = nil</div><div>isEven = { n in</div><div>    if n == 0 {</div><div>        return true</div><div>    } else {</div><div>        return isOdd(n - 1)</div><div>    }</div><div>}</div><div>isOdd = { n in</div><div>    if n == 0 {</div><div>        return false;</div><div>    } else {</div><div>        return isEven(n - 1)</div><div>    }</div><div>}</div><div>isEven(4) // True</div><div>isOdd(4) // False</div><div><br></div><div>struct GenericIncrement&lt;T: Numeric&gt; {</div><div>    let increment = { (n: T) -&gt; T in</div><div>        n + 1</div><div>    }</div><div>}</div><div>let int = GenericIncrement&lt;Int&gt;() // Reify increment and name mangle!</div><div>int.increment(1) // 2</div><div>let double = GenericIncrement&lt;Double&gt;()</div><div>double.increment(1.1) // 2.1</div></blockquote><div><div><br></div><div>The reason for showing code above is to demonstrate that the compiler could do this (in fact it could do better) - I am not suggesting anyone uses the above! </div></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 28 October 2017 at 10:01, Slava Pestov 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">That sounds like a bug, and it could occur with closure expressions also, since at the SILGen level and below they’re basically the same thing. Please file a bug if you come up with a reduced test case.<br>
<br>
Slava<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; On Oct 27, 2017, at 4:00 PM, Jon Gilbert &lt;<a href="mailto:swiftevolution@jongilbert.com">swiftevolution@jongilbert.com</a><wbr>&gt; wrote:<br>
&gt;<br>
&gt; I have run into nondescript compiler crashes (like segmentation faults, etc.) when using local functions to do certain things, like wrapping the parent function’s escaping closure arguments in other closures that capture variables from the parent function’s local scope, especially when those variables themselves are function types that do the wrapping, and therefore take closures as arguments. (Of course, all of these closures taking generic arguments conforming to protocols with associated types made things extra interesting.)<br>
&gt;<br>
&gt; I don’t know if this makes local functions actively harmful, or if it means function types in capture lists need to support @escaping, but it does remind me to go back and try to reproduce those weird issues in a sample project or playground page so I can make a bug report to Apple.<br>
&gt;<br>
&gt; Jonathan<br>
&gt;<br>
&gt;&gt; On Oct 27, 2017, at 12:29, Slava Pestov via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I mean, we could remove a lot of language features without giving up turing completeness. But I’ve personally used local functions in multiple languages and found them useful. I certainly don’t see why the feature is actively harmful, which is the criteria for introducing a source breaking change in Swift 5.<br>
&gt;<br>
<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>
</div></div></blockquote></div><br></div>