> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
>> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution
>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
