<div dir="ltr"><span style="font-size:12.8px">Allow function types that are both let and initialized to be annotated with </span><span style="font-size:12.8px">@inline. If closures get more features then we fix the bug pointed out with local functions and we get better closures. Good bang for the buck.</span><br></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 27 October 2017 at 12:22, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>i use a lot of local @inline(__always) functions as a sort of weird macro so this change would be hugely source breaking. Also can you even annotate a function object as force-inlineable?</div><div><div class="h5"><div><br>On Oct 26, 2017, at 6:45 PM, Howard Lovatt 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><div dir="ltr">The issues raised about local capture by local (inner) functions are valid, likewise the discussion about the @nonescaping annotation are also valid.<div><br></div><div>Rather than expand local function syntax why not deprecate local functions completely and add the @nonescaping annotation to local closures following the argument syntax, e.g. the running example:</div><div><br></div><div> </div> class A {<div> func foo() {</div><div> let local: @nonescaping () -> void = {<br> bar() // Capture of self does not need to be explicit in the closure because it is non-escaping.<br> }</div><div> local()</div><div> }</div><div> func bar() { ... }</div><div> }</div><div><br></div><div>This is a simpler and more powerful solution (I think others have pretty much suggested the same thing in this forum but have not explicitly said get rid of local functions).</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_472054313698251596gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 27 October 2017 at 08:16, Mike Kluev 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>On 26 October 2017 at 20:24, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></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">I don’t see how this makes any sense or be possible:<br><div><div><br></div><div>* It doesn’t make sense for me because local is not a member function of A.</div><div>* It would cause ambiguity when trying to call another member function with the same name as the local function.</div></div></div></blockquote><div><br></div></span><div>in the escaping contexts, "self." is currently required before the instance members (**). </div><div>the idea is to require it before some local functions as well, recursively analysing what these local functions do (at the compile time).</div><div><br></div><div>/* local */ foo() {</div><div> bar()</div><div> variable = 1</div><div>}</div><div><br></div><div>...</div><div>self.foo()</div><div><br></div><div>// self is required because the compiler knows what's inside, and if it were to put the content inline that would be:<br></div><div><br></div><div>// inlining foo pseudo code:</div><div> self.bar()</div><div> self.variable = 1</div><div><br></div><div>hence the compiler can figure out that in this case "self" is required before foo()</div><div><br></div><div>on the other hand:</div><div><br></div><div>/* local */ poo() {</div><div> print("doesnt not capture anything")</div><div>}</div><div><br></div><div>here, if compiler were to use poo in the escaping context it would not require "self." before it.</div><div><br></div><div>this decision (whether to require "self." on not) can be on the use side.</div><div><br></div><div>(**) FTM, the normal instance methods that do not capture anything may as well not require "self." before them in escaping contexts:</div><div><br></div><div>/* non local */ baz() {</div><div> print("doesn't capture anything")</div><div>}</div><span class="m_472054313698251596HOEnZb"><font color="#888888"><div><br></div><div>Mike</div><div><br></div></font></span></div></div></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></div></blockquote></div><br></div>