On 14 November 2017 at 19:02, Mike Kluev <[email protected]> wrote:
> On Mon, 13 Nov 2017 22:30:25 +0100 David Hart <[email protected]> wrote: > > > On 13 Nov 2017, at 05:52, Slava Pestov <[email protected]> wrote: >> > >> >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution < >> [email protected]> wrote: >> >> >> >> 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. >> > > adding to the list of options: > > 6. func fn<T>(param: T) throws -> T where T: Equatable [foo, bar] { … } > > otherwise +1 to #1 and to the one in proposal. also see about #4 below. > > plus, if 90%+ of use cases in practice would be [weak self] -- (the only > examples shown in the proposals FTM) -- i would strongly consider this > syntax sugar in addition to a generic notation: > > weak func fn<T>(param: T) throws -> T where T: Equatable { … } > > works with "unowned" as a bonus. > > if implement this sugar than some variation of #4 looks appealing to have > these capture things close. > > the closer we have it to this English sentence the better IMHO: weak throwing function "fn", capturing "foo" and "bar" weakly, using generic type "T" which is "Equatable", having parameter "param" of type "T", returning type "T", with the following body { ... } Mike
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
