Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

On 21 November 2017 at 21:55, Mike Kluev wrote: > > maybe this? > > { > capture weak foo, loo, poo // "capture list", if present > capture unowned bar, baz, booz // shall be at the beginning > capture weak delegate = self.delegate! // before anything else > > foo() >

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On 13. Nov 2017, at 05:11, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of improving capturing semantics of >> local functions, Alex

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

on Tue, 21 Nov 2017 11:06:04 +0100 Tino Heth <2...@gmx.de> wrote: > > > 5. func fn[foo, bar](param: T) throws -> T where T: Equatable > captures [foo, bar] { … } > > I guess it can be considered good practice to start a line with the most > important information, and move the details to the far ri

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> 5. func fn[foo, bar](param: T) throws -> T where T: Equatable captures > [foo, bar] { … } I guess it can be considered good practice to start a line with the most important information, and move the details to the far right, so that they don’t distract the hasty reader. I’m not sure if the c

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> Am 21.11.2017 um 04:00 schrieb Chris Lattner via swift-evolution > : > > >> On Nov 12, 2017, at 8:52 PM, Slava Pestov via swift-evolution >> wrote: >> >> >> func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } > > +1, potentially adding a context sensitive keyword like “ca

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 8:52 PM, Slava Pestov via swift-evolution > wrote: > > > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } +1, potentially adding a context sensitive keyword like “capturing” before it. > I think #4 is ambiguous with array literals unfortunately. > > P

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> Secondly, this proposal suggests allowing the same capture list syntax from >> closures in local functions. Capture lists would still be invalid in >> top-level and member functions. > > > I think this i

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

I think you have changed my mind. Virtually everything I want to do can be achieved by having a closure as an alternative syntax for a function. Particularly if you could assign to a `var`. You still need extra syntax for generics and escaping closures. On Fri, 17 Nov 2017 at 1:45 pm, Slava Pestov

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 16, 2017, at 4:38 PM, Howard Lovatt wrote: > > When the user writes: > > let increment: (T) throws -> T where T: Numeric = { $0 + 1 } > increment(1) // 2 > increment(1.1) // 2.1 This means that ‘increment’ is a *value* with a generic function type. Presumably you want to

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

No I am proposing 1st class values via the name mangling. But I made a mistake in the code posted - cut and past error from an earlier playground - sorry. Which almost certainly confused you. Anywhere `(T) throws -> T where T: Numeric` appears it is replaced by `_Function1__T1__T1__T1__E__Numeric`

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 16, 2017, at 3:07 PM, Howard Lovatt via swift-evolution > wrote: > > Where I am proposing a change is that if a closure with generic arguments is > encountered it is transformed into the equivalent struct and the struct is > typed as it currently is (or if there is a better implemen

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> Am 17.11.2017 um 00:00 schrieb Slava Pestov : > > Remember that only references can be captured weakly, not value types, even > if those value types contain reference members… so this might end up being > more confusing than necessary. true… but isn’t that a constellation with potential for

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

I am not proposing a change to the type system at all. Absolutely no change whatsoever in any form. I don't know how to say this more clearly. Therefore your example of: let f = { x in { y in y } } Remains illegal and is treated by the compiler exactly like it is currently treated and like i

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 16, 2017, at 2:56 PM, Tino Heth via swift-evolution > wrote: > > >> the stat suggests that in 90%+ real-life cases [weak self] is used so the >> "weak func" syntax sugar is worth to consider as an addition to this >> proposal. > Slightly OT: > Just thought about making all captures

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> the stat suggests that in 90%+ real-life cases [weak self] is used so the > "weak func" syntax sugar is worth to consider as an addition to this proposal. Slightly OT: Just thought about making all captures weak by default… I know it’s probably to late for such a change, but I wonder if this w

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

Sorry for the delay in replying - I was called up for jury duty! For recursive closures the compiler would require two changes; if the variable is a function type then: 1. It can reference itself, e.g. `let fact: (Int) -> Int = { $0 < 2 ? 1 : $0 * fact($0 - 1) }` becomes legal. This is not diff

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

~Robert Widmann 2017/11/14 22:02、Matthew Johnson via swift-evolution のメール: > > > Sent from my iPhone > >> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution >> wrote: >> >> Having read all the arguments for what to add to local functions it still >> strikes me as a poor use

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

A quick thing I noticed on a first read (sort of tangential to the rest of the discussion) is that it would be a good idea to land warnings for potential reference cycles sooner rather than later. I have an (un-rebased) branch that lays out what parts of Sema needs to be touched to make this ha

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On 15 Nov 2017, at 03:56, Howard Lovatt via swift-evolution > wrote: > > Having read all the arguments for what to add to local functions it still > strikes me as a poor use of engineering resources to fix them (though I do > agree they have problems). A better use of resources would be: >

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution > wrote: > > 2. Allow closures when assigned to a function type to be: > 2a. Recursive. Local functions can also be mutually recursive: func f() { func foo() { bar() } func bar() { foo() } } This would not work wit

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 14, 2017, at 7:31 PM, Howard Lovatt via swift-evolution > wrote: > > You can add generic closures with some name mangling and simple > transformations, nothing very hard. > > The compiler can emit the following for example: > > // User writes > let increment: (T) -> T = { $0 + 1 }

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

On 14 November 2017 at 21:36, Mike Kluev wrote: > > it might cover well over 90% of use cases (by my "pessimistic" > estimate)... if someone has a quick way to scan and analyse, say, github > swift sources we may even know that current percentage number of real life > usage. > i did a quick & di

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

You can add generic closures with some name mangling and simple transformations, nothing very hard. The compiler can emit the following for example: // User writes let increment: (T) -> T = { $0 + 1 } increment(1) // 2 increment(1.1) // 2.1 // Compiler issues struct _Generic_Increment { // Mang

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

Sent from my iPhone > On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution > wrote: > > Having read all the arguments for what to add to local functions it still > strikes me as a poor use of engineering resources to fix them (though I do > agree they have problems). A better use

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

Having read all the arguments for what to add to local functions it still strikes me as a poor use of engineering resources to fix them (though I do agree they have problems). A better use of resources would be: 1. Deprecate local functions. 2. Allow closures when assigned to a function type t

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

The inference algebra just suggested was enjoyable to read, but is still a new syntax. Which is interesting and deserving of its own proposal. The purpose of this proposal is simply to introduce the existing capture syntax to local functions. Thanks to everyone's feedback pointing out that the `sel

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

On 14 November 2017 at 21:02, David Hart wrote: > > > I’d be very hesitant to introduce this syntax: > > >- it’s new syntax, so it comes with a complexity tax (it isn’t >naturally obvious what it means for a func to be weak) >- it’s only sugar for the capture of self > > it might cove

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On 14 Nov 2017, at 20:41, Wallacy wrote: > > > > Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution > mailto:swift-evolution@swift.org>> escreveu: > On Mon, 13 Nov 2017 22:30:25 +0100 David Hart > wrote: > > On 13 Nov 2017, at 05:52, Slava Pestov

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution < swift-evolution@swift.org> escreveu: > On Mon, 13 Nov 2017 22:30:25 +0100 David Hart wrote: > >> > On 13 Nov 2017, at 05:52, Slava Pestov wrote: >> > >> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

On 14 November 2017 at 19:17, Mike Kluev wrote: > On 14 November 2017 at 19:02, Mike Kluev wrote: > >> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart wrote: >> >> > On 13 Nov 2017, at 05:52, Slava Pestov wrote: >>> > >>> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

On 14 November 2017 at 19:02, Mike Kluev wrote: > On Mon, 13 Nov 2017 22:30:25 +0100 David Hart wrote: > > > On 13 Nov 2017, at 05:52, Slava Pestov wrote: >> > >> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> >> By analogy

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

On Mon, 13 Nov 2017 22:30:25 +0100 David Hart wrote: > On 13 Nov 2017, at 05:52, Slava Pestov wrote: > > > >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> By analogy with the current closure syntax, the capture list ought to

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

I think it would be unfortunate to have the capture list before the template parameters: Template parameters might be used in the capture list, and although Swift doesn’t rely on strict „linearity“ or forward declarations, I don’t want to be forced to use things that aren’t declared yet. ___

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On 13 Nov 2017, at 05:52, Slava Pestov wrote: > > > >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >>> wrote: >>> >>> Hello evolution folks, >>> >>> After the positive feedback on th

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 11:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of improving capturing semantics of >> local functions, Ale

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> Another option that reads nicely IMHO is > > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } > I changed my mind. Putting the capture list just before { } is where I'd rather see it. > I think #4 is ambiguous with array literals unfortunately. > > Perhaps this proposal

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of improving capturing semantics of >> local functions, Ale

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

I'd vote for # 1 Starting with "func" helps signal that the context is a function. (Though I know some things can precede "func".) Having the function name second is important to me: you don't have to scan further for its name. Template arguments seem more important than capture lists, so I'

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution > wrote: > > Hello evolution folks, > > After the positive feedback on the idea of improving capturing semantics of > local functions, Alex Lynch and I worked on a proposal. Please let us know if > you have any feedback: > > http

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

Imho it’s good to copy the concept of capture lists — but it could be done differently, without polluting the body: func foo[capture list](parameters) {} I’m not sure if there are corner cases with subscript-syntax, but in general, I think this approach is nicer. - Tino _

[swift-evolution] [Pitch] Improving capturing semantics of local functions

Hello evolution folks, After the positive feedback on the idea of improving capturing semantics of local functions, Alex Lynch and I worked on a proposal. Please let us know if you have any feedback: https://github.com/hartbit/swift-evolution/blob/improving-capturing-semantics-of-local-function