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 > <[email protected]> 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 >> <[email protected]> wrote: >>> On 26 October 2017 at 20:24, David Hart <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
