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

Slava Pestov spestov at apple.com
Sun Nov 12 22:52:28 CST 2017



> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution <swift-evolution at swift.org> 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:
>> 
>> https://github.com/hartbit/swift-evolution/blob/improving-capturing-semantics-of-local-functions/proposals/XXXX-improve-capture-semantics-of-local-functions.md
> 
> So, quoting the proposal:
> 
>> First of all, this proposal suggests extending the requirement of the self. prefix to local functions, but only if the local function is used as or used inside an escaping closure.
> 
> I don't love that the use of a function many lines away can cause errors in that closure. There's a "spooky action-at-a-distance" quality to this behavior that I don't like.

Agreed.

> I think this is a good idea, but I don't like bringing the already weird use of `in` to actual functions.
> 
> By analogy with the current closure syntax, the capture list ought to go somewhere before the parameter list, in one of these slots:
> 
> 1.	func fn<T>[foo, bar](param: T) throws -> T where T: Equatable { … }
> 2.	func fn[foo, bar]<T>(param: T) throws -> T where T: Equatable { … }
> 3.	func [foo, bar] fn<T>(param: T) throws -> T where T: Equatable { … }
> 4.	[foo, bar] func fn<T>(param: T) throws -> T where T: Equatable { … }
> 
> Of these options, I actually think #4 reads best; 1 and 2 are very cluttered, and 3 just seems weird. But it seems like the one that would be easiest to misparse.

Another option that reads nicely IMHO is

func fn<T>(param: T) throws -> T where T : Equatable [foo, bar] { … }

I think #4 is ambiguous with array literals unfortunately.

Perhaps this proposal should be split in two — the ‘self.’/escaping part is source breaking, and will likely require more discussion. Adding capture lists to local functions seems like a more straightforward change.

Slava

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list