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