> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org> 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 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.
This is relatively rare, so I’d suggest introducing a context sensitive keyword
to make it explicit, perhaps:
5. func fn<T>[foo, bar](param: T) throws -> T where T: Equatable captures [foo,
bar] { … }
It makes sense (IMO) to keep it near the body of the function, since it is more
an artifact of the implementation than it is about the API. Yes I know that
caring about the API of a local function is weird :-)
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
