Re: [swift-evolution] Making capturing semantics of local

> On 29 Oct 2017, at 3:01 pm, Mike Kluev wrote: > >> On 29 October 2017 at 14:02, Johannes Weiß wrote: >> >> Definitely not arguing with that. But there are (valid?) cases when you want >> a recursive closure which doesn’t have a native

Re: [swift-evolution] Making capturing semantics of local

On 28 October 2017 at 00:00, Slava Pestov wrote: > 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. > > indeed: let closure = {} print("closure is \(closure)") // prints:

Re: [swift-evolution] Making capturing semantics of local

On 29 October 2017 at 14:02, Johannes Weiß wrote: Definitely not arguing with that. But there are (valid?) cases when you > want a recursive closure which doesn’t have a native recursion mechanism > and then `fix` can be useful I’d argue. I think more straightforward

Re: [swift-evolution] Making capturing semantics of local

> On 28 Oct 2017, at 10:14 pm, John McCall wrote: > > >> On Oct 28, 2017, at 6:05 AM, Johannes Weiß via swift-evolution >> wrote: >> >> Hi Mike, >> >>> On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote: >>> >>> on Date:

Re: [swift-evolution] Making capturing semantics of local

On 28 October 2017 at 23:45, Mike Kluev wrote: > on Date: Fri, 27 Oct 2017 15:15:15 -0400 Alex Lynch > wrote: > > I use local functions heavily in my day-to-day workflow and an very >> interested in them supporting capture lists. >> Here is a draft

Re: [swift-evolution] Making capturing semantics of local

on Date: Fri, 27 Oct 2017 15:15:15 -0400 Alex Lynch wrote: I use local functions heavily in my day-to-day workflow and an very > interested in them supporting capture lists. > Here is a draft feature specification: > https://bitbucket.org/snippets/lynchrb/r487zn > > Anyone

Re: [swift-evolution] Making capturing semantics of local

> On Oct 28, 2017, at 6:05 AM, Johannes Weiß via swift-evolution > wrote: > > Hi Mike, > >> On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote: >> >> on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß >> wrote: >>

Re: [swift-evolution] Making capturing semantics of local

> On Oct 28, 2017, at 1:47 AM, Tino Heth via swift-evolution > wrote: > > How about > func localFunc[weak self](input: Double) { > } > ? > Seems to be the obvious choice for me... +1 -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? *

Re: [swift-evolution] Making capturing semantics of local

Hi Mike, > On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote: > > on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß > wrote: > > > On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution > > wrote: > > > > In

Re: [swift-evolution] Making capturing semantics of local

How about func localFunc[weak self](input: Double) { } ? Seems to be the obvious choice for me... ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Making capturing semantics of local

> On Oct 27, 2017, at 9:42 PM, Howard Lovatt via swift-evolution > wrote: > > I should qualify that I am not proposing removing local functions without > replacing them with closures that have the same power. If we can unify the two syntaxes, maybe. But even if

Re: [swift-evolution] Making capturing semantics of local

I should qualify that I am not proposing removing local functions without replacing them with closures that have the same power. I don't believe powerful closures are something the compiler couldn't do, in fact I believe it is something that is relatively easy. I believe this because there isn't

Re: [swift-evolution] Making capturing semantics of local

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. Slava > On Oct 27, 2017, at 4:00 PM, Jon Gilbert > wrote:

Re: [swift-evolution] Making capturing semantics of local

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

Re: [swift-evolution] Making capturing semantics of local

> On Oct 27, 2017, at 10:51 AM, Mike Kluev wrote: > > On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov > wrote: > > Closures cannot replace all uses of local functions. Local functions can be > recursive, and have a generic

Re: [swift-evolution] Making capturing semantics of local

I use local functions heavily in my day-to-day workflow and an very interested in them supporting capture lists. Here is a draft feature specification: https://bitbucket.org/snippets/lynchrb/r487zn Anyone see any weak spots? Alex On Fri, Oct 27, 2017 at 12:54 AM, Slava Pestov via

Re: [swift-evolution] Making capturing semantics of local

on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß < johanneswe...@apple.com> wrote: > On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote: > > > > In terms of recursion you can fiddle it: > > > > struct RecursiveClosure { > > var c: C! = nil

Re: [swift-evolution] Making capturing semantics of local

On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov wrote: > > Closures cannot replace all uses of local functions. Local functions can > be recursive, and have a generic parameter list. > > FTM, local functions do not help with "keep functions short" and "keep indentation level

Re: [swift-evolution] Making capturing semantics of local

> On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution > wrote: > > > Closures cannot replace all uses of local functions. Local functions can be > > recursive, and have a generic parameter list. > > My response would be add these featurtes to closures,

Re: [swift-evolution] Making capturing semantics of local

> On 26 Oct 2017, at 21:40, John McCall wrote: > >> On Oct 26, 2017, at 3:24 PM, David Hart > > wrote: >>> On 26 Oct 2017, at 21:16, John McCall via swift-evolution >>>

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 10:27 PM, Howard Lovatt wrote: > > > Closures cannot replace all uses of local functions. Local functions can be > > recursive, and have a generic parameter list. > > My response would be add these featurtes to closures, it will make closures >

Re: [swift-evolution] Making capturing semantics of local

> Closures cannot replace all uses of local functions. Local functions can be recursive, and have a generic parameter list. My response would be add these featurtes to closures, it will make closures better. In terms of recursion you can fiddle it: struct RecursiveClosure { var c: C! = nil

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 9:53 PM, Howard Lovatt via swift-evolution > wrote: > > It would be easy to provide a fixit. That is still a source breaking change that requires migration, though. > How often are they actually used? I rarely use them and all my use cases >

Re: [swift-evolution] Making capturing semantics of local

It would be easy to provide a fixit. How often are they actually used? I rarely use them and all my use cases could be a closure instead. Also see Mike Kluev example; local functions are arguably worse than closures in all cases (provided that you can appropriately annotate the function type).

Re: [swift-evolution] Making capturing semantics of local

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

Re: [swift-evolution] Making capturing semantics of local

On 27 October 2017 at 00:45, Howard Lovatt wrote: > Rather than expand local function syntax why not deprecate local functions > completely > a cautious +0.5. local functions do not add that much value as one would hope and beyond what's already discussed above,

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 4:45 PM, Howard Lovatt via swift-evolution > wrote: > > Rather than expand local function syntax why not deprecate local functions > completely I don’t think at this point such a drastic change to the language is likely to happen.

Re: [swift-evolution] Making capturing semantics of local

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 > wrote: > >

Re: [swift-evolution] Making capturing semantics of local

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

Re: [swift-evolution] Making capturing semantics of local

On 26 October 2017 at 20:24, David Hart 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

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 3:24 PM, David Hart wrote: >> On 26 Oct 2017, at 21:16, John McCall via swift-evolution >> > wrote: >> >>> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution >>>

Re: [swift-evolution] Making capturing semantics of local

> On 26 Oct 2017, at 21:16, John McCall via swift-evolution > wrote: > >> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution >> > wrote: >> on Wed, 25 Oct 2017 13:41:40 +0200 David Hart

Re: [swift-evolution] Making capturing semantics of local

On 26 October 2017 at 19:19, Mike Kluev wrote: > on Wed, 25 Oct 2017 13:41:40 +0200 David Hart wrote: > > class A { >> func foo() { >> func local() { >> bar() // error: Call to method ‘bar' in function ‘local' >> requires explicit

Re: [swift-evolution] Making capturing semantics of local

on Wed, 25 Oct 2017 13:41:40 +0200 David Hart wrote: class A { > func foo() { > func local() { > bar() // error: Call to method ‘bar' in function ‘local' > requires explicit 'self.' to make capture semantics explicit > } > > // ... >

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On 25. Oct 2017, at 13:41, David Hart via swift-evolution > wrote: > > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find

Re: [swift-evolution] Making capturing semantics of local functions explicit

Hi, > On 25 Oct 2017, at 6:01 pm, John McCall via swift-evolution > wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> wrote: >> I got bit again by a sneaky memory leak concerning local functions and would >> like

Re: [swift-evolution] Making capturing semantics of local functions explicit

class A { func foo() -> ()->String { func local() -> String { [weak self] in return "foo \(self.i)" } return local } ... compares well with this... class A { func foo() -> ()->String { let local : () -> String = { [weak self] in

Re: [swift-evolution] Making capturing semantics of local functions explicit

i support this™ On Wed, Oct 25, 2017 at 6:41 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > I got bit again by a sneaky memory leak concerning local functions and > would like to discuss a small language change. I vaguely remember this > being discussed in the past, but

Re: [swift-evolution] Making capturing semantics of local functions explicit

I agree; I think the 'in' should be there. This should be fairly straight-forward to implement right? It's just alternative syntax over existing behavior. (thinking about the proposal now...) On Wed, Oct 25, 2017 at 5:45 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:21 PM, David Hart wrote: >> On 25 Oct 2017, at 19:01, John McCall > > wrote: >> >>> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >>>

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On 25 Oct 2017, at 19:01, John McCall wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> > wrote: >> I got bit again by a sneaky memory leak concerning local functions and would >> like

Re: [swift-evolution] Making capturing semantics of local functions explicit

Does the compiler treat a nested function differently from a closure in any meaningful way? (I suppose they might have symbols emitted in the symbol table, whereas a closure assigned to a local variable wouldn't?) It definitely seems odd that you can write two functionally equivalent pieces of

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:41 AM, David Hart via swift-evolution > wrote: > > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution > wrote: > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find the