<div dir="ltr">On 14 November 2017 at 19:17, Mike Kluev <span dir="ltr"><<a href="mailto:mike.kluev@gmail.com" target="_blank">mike.kluev@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-">On 14 November 2017 at 19:02, Mike Kluev <span dir="ltr"><<a href="mailto:mike.kluev@gmail.com" target="_blank">mike.kluev@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>On Mon, 13 Nov 2017 22:30:25 +0100 David Hart <<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>> wrote:<br></div><div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> On 13 Nov 2017, at 05:52, Slava Pestov <<a href="mailto:spestov@apple.com" target="_blank">spestov@apple.com</a>> wrote:<br>><br>
>> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>>> By analogy with the current closure syntax, the capture list ought to go somewhere before the parameter list, in one of these slots:<br>
>><br>
>> 1. func fn<T>[foo, bar](param: T) throws -> T where T: Equatable { … }<br>
>> 2. func fn[foo, bar]<T>(param: T) throws -> T where T: Equatable { … }<br>
>> 3. func [foo, bar] fn<T>(param: T) throws -> T where T: Equatable { … }<br>
>> 4. [foo, bar] func fn<T>(param: T) throws -> T where T: Equatable { … }<br>
>><br>
>> 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.<br>
><br>
> Another option that reads nicely IMHO is<br>
><br>
> func fn<T>(param: T) throws -> T where T : Equatable [foo, bar] { … }<br>
><br>
> I think #4 is ambiguous with array literals unfortunately.<br></blockquote><div><br></div><div>adding to the list of options:</div><div><br></div><div>6. func fn<T>(param: T) throws -> T where T: Equatable [foo, bar] { … }</div><div><br></div><div>otherwise +1 to #1 and to the one in proposal. also see about #4 below.</div><div><br></div><div>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:</div><div><br></div><div>weak func fn<T>(param: T) throws -> T where T: Equatable { … }</div><div><br></div><div>works with "unowned" as a bonus.</div><div><br></div><div>if implement this sugar than some variation of #4 looks appealing to have these capture things close.</div><span class="gmail-m_1837818293331903322gmail-HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></div></blockquote><div><br></div></span><div>the closer we have it to this English sentence the better IMHO:</div><div><br></div><div>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 { ... } </div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>this is the closet one (hence +1 to #2):</div><div><br></div><div>weak throwing func fn [foo, bar] <T: Equatable> (param: T) -> T {...}</div><div><br></div><div>Mike</div><div><br></div></div></div></div>