> On 13 Nov 2017, at 05:52, Slava Pestov <spes...@apple.com> wrote:
>
>
>
>> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution
>>> <swift-evolution@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.
Thanks Brent, Slava and John for your feedback. I think you are right: I picked
up the idea from the original thread because it would reduce source breakage,
but I’m starting to thing its just not worth it.
Concerning the alternative solution of annotating local functions with
@escaping, it’s definitely an interesting idea. It might be slightly more
source-breaking but, as mentioned in the proposal, the breakage will attract
attention to code where its easy to unknowingly create memory leaks.
>> 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.
This is pure aesthetics, but I’m a bit bothered by all 5 options. Local
functions and closures are syntactically different enough that we can either
choose to keep capture lists in the same position relative to the curly braces
(like I proposed), or relative to the parameters (like Brent proposes). Don’t
you think that the suggestion in the pitch is the least confusing for users? On
a side note, Slava’s 5th option seems like its breaking relative position with
the curly braces and the parameters.
> 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.
Seems like a good idea. Once we all come close to an agreement, Alex and I can
spit them into two proposals.
David.
> Slava
>
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
