[swift-evolution] Making capturing semantics of local

[Howard Lovatt]

Allow function types that are both let and initialized to be annotated
with @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.

  -- Howard.

On 27 October 2017 at 12:22, Taylor Swift <kelvin13ma at gmail.com> wrote:

> 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?
>
> On Oct 26, 2017, at 6:45 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> The issues raised about local capture by local (inner) functions are
> valid, likewise the discussion about the @nonescaping annotation are also
> valid.
>
> 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:
>
>
>     class A {
>         func foo() {
>             let local: @nonescaping () -> void = {
>                 bar() // Capture of self does not need to be explicit in
> the closure because it is non-escaping.
>             }
>             local()
>         }
>         func bar() { ... }
>     }
>
> 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).
>
>   -- Howard.
>
> On 27 October 2017 at 08:16, Mike Kluev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On 26 October 2017 at 20:24, David Hart <david at hartbit.com> wrote:
>>
>>> I don’t see how this makes any sense or be possible:
>>>
>>> * It doesn’t make sense for me because local is not a member function of
>>> A.
>>> * It would cause ambiguity when trying to call another member function
>>> with the same name as the local function.
>>>
>>
>> in the escaping contexts, "self." is currently required before the
>> instance members (**).
>> the idea is to require it before some local functions as well,
>> recursively analysing what these local functions do (at the compile time).
>>
>> /* local */ foo() {
>>     bar()
>>     variable = 1
>> }
>>
>> ...
>> self.foo()
>>
>> // self is required because the compiler knows what's inside, and if it
>> were to put the content inline that would be:
>>
>> // inlining foo pseudo code:
>>      self.bar()
>>      self.variable = 1
>>
>> hence the compiler can figure out that in this case "self" is required
>> before foo()
>>
>> on the other hand:
>>
>> /* local */ poo() {
>>     print("doesnt not capture anything")
>> }
>>
>> here, if compiler were to use poo in the escaping context it would not
>> require "self." before it.
>>
>> this decision (whether to require "self." on not) can be on the use side.
>>
>> (**) FTM, the normal instance methods that do not capture anything may as
>> well not require "self." before them in escaping contexts:
>>
>> /* non local */ baz() {
>>     print("doesn't capture anything")
>> }
>>
>> Mike
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171027/bad8a06e/attachment.html>