<div dir="ltr">I am not proposing a change to the type system at all. Absolutely no change whatsoever in any form. I don't know how to say this more clearly.<div><br></div><div>Therefore your example of:</div><div><br></div><div> let f = { x in { y in y } }</div><div><br></div><div>Remains illegal and is treated by the compiler exactly like it is currently treated and like it currently does results in "error: type of expression is ambiguous without more context".</div><div><br></div><div>Where I am proposing a change is that if a closure with generic arguments is encountered it is transformed into the equivalent struct and the struct is typed as it currently is (or if there is a better implementation something equivalent to this), therefore zero change to the type system.</div><div><br></div><div>The changes proposed are a transformation into a struct and name mangling, e.g.:</div><div><br></div><div><div> let increment: <T>(T) throws -> T where T: Numeric = { $0 + 1 }</div></div><div><div> let increment = { <T>(n: T) throws -> T where T: Numeric in n + 1 }</div></div><div><div> let increment: <T>(T) throws -> T where T: Numeric = { <T>(n: T) throws -> T where T: Numeric in n + 1 }</div></div><div><br></div><div>Are all the same and would therefore all become:</div><div><br></div><div> struct _Function1__T1__T1__T1__E__Numeric<T> where T: Numeric { // Mangle name</div><div> let call: (T) throws -> T = { $0 + 1 }</div><div> }</div><div><br></div><div>Which is a trivial transformation; a simple one to one correspondence. </div><div><br></div><div>The hard part is actually mangling the name into a canonical form, I propose:</div><div><br></div><div> 1. If the function type has 1 argument its name begins `_Function1_`, 2 arguments; `_Function2_`, etc.</div><div> 2. The 1st generic type is called `_T1_`, 2nd; `_T2_`, etc.</div><div> 3. A function that doesn't return anything has a return type of `_V_`.</div><div> 4. Other types are their normal name pretended with an underscore, i.e. `Numeric` becomes `_Numeric` in running example.</div><div> 5. The function argument types are then listed in order followed by the return type, i.e. `_T1__T1_` which follows `_Function1_` in example.</div><div> 6. Type constraints are converted to the equivalent where clause, e.g. `let increment: <T: Numeric>(T) throws -> T` is converted to `let increment: <T>(T) throws -> T where T: Numeric`.</div><div> 7. The where clause is converted to the converted names, e.g. `where T: Numeric` becomes `where _T1_: _Numeric`.</div><div> 8. The where clause is sorted so that constraints on T1 are listed first etc., e.g. `where _T2_: _Numeric, _T1_: _Numeric` becomes `where _T1_: _Numeric, _T2_: _Numeric`.</div><div> 9. Relationships between types are sorted, e.g. `where _T2_.Element == _T1_.Element` becomes `where _T1_.Element == _T2_.Element`.</div><div> 10. The `where` keyword and spaces are deleted and `:` becomes `_E_`, `.` becomes `_D_`, and `,` becomes `_C_`, the final part of the running example is therefore `_T1__E__Numeric`.</div><div><br></div><div>Since the name mangling is the tricky bit this would be the main work to see if the above scheme is robust.</div><div><br></div><div>But wouldn't it be great to have generic closures :).</div><div> </div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 15 November 2017 at 19:11, Robert Widmann <span dir="ltr"><<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span></span></div><div><br><br><div id="m_-4753880595475437584AppleMailSignature">~Robert Widmann </div><div><br>2017/11/14 22:02、Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>><wbr>のメール:<br><br></div><blockquote type="cite"><div><br><br><div id="m_-4753880595475437584AppleMailSignature">Sent from my iPhone</div><span class=""><div><br>On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div></span><blockquote type="cite"><div><div dir="ltr"><span class="">Having read all the arguments for what to add to local functions it still strikes me as a poor use of engineering resources to fix them (though I do agree they have problems). A better use of resources would be:<div><br></div><div> 1. Deprecate local functions.</div></span><span class=""><div> 2. Allow closures when assigned to a function type to be:</div><div> 2a. Recursive.</div><div> 2b. Annotatable with:</div><div> 2bi. @inline</div><div> 2bii. @escaping</div><div> 2c. Generic.</div><div><br></div><div>That would be a similar engineering effort and give a better short term result of better closures which would be much more widely applicable as well as addressing the issues with local functions.</div></span></div></div></blockquote><div><br></div><span class="">I believe generic closures would require adding higher rank types to Swift. That would be pretty cool but I suspect the engineering effort is at least an order of magnitude greater than the changes discussed in this thread.</span></div></blockquote><div><br></div>100% correct. Slava raises good points about implementation, I’ll raise one about semantics:<div><br></div><div>Without sufficient restrictions on this kind of polymorphism, type checking will become significantly more difficult for little corresponding benefit. Enabling the formation of polymorphic types just because you’re near an arrow means all sorts of fun things now get to happen</div><div><br></div><div>let f = { x in { y in y } }</div><div><br></div><div>This program is illegal without a type signature, but still <i>typeable </i>in that Swift will try to look for bindings to the tn’s in this signature</div><div><br></div><div>f : <T0, T1> (T0) -> (T1) -> T1</div><div><br></div><div>This is good - this is the most general unifier for this expression promised to us by the “Hindley-Milner-like” label we have in the type checker docs.</div><div><br></div><div>Given even rank-2 types, the most general unifier is (ideally) now </div><div><div><br></div><div>f : <T0> (T0) -> (<T1> (T1) -> T1)</div><div><br></div><div>Which is significant because despite an obvious isomorphism, the former is <b>not</b> a specialization of the latter. It is a completely separate polytype that would require additional structural rules to recover the correct behavior. This can also block inference or generate counterintuitive unifiers if we’re forced to e.g. unify nested polytypes against each other.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>~Robert Widmann</div></font></span><div><div class="h5"><div><br><blockquote type="cite"><div><div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>It also gives a better long term result of not having to maintain local functions.</div><div> </div></div><div class="gmail_extra"><br clear="all"><div><div class="m_-4753880595475437584gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 15 November 2017 at 09:08, Alex Lynch via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The inference algebra just suggested was enjoyable to read, but is still a new syntax. Which is interesting and deserving of its own proposal. The purpose of this proposal is simply to introduce the existing capture syntax to local functions. Thanks to everyone's feedback pointing out that the `self` reference analysis is a deeper question than initially realized. <div><br></div><div>Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-4753880595475437584h5">On Tue, Nov 14, 2017 at 4:36 PM, Mike Kluev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-4753880595475437584h5"><div dir="ltr"><span>On 14 November 2017 at 21:02, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span><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 style="word-wrap:break-word;line-break:after-white-space"><br><div><span class="m_-4753880595475437584m_6043367993829337200m_-5026886634801406416gmail-"><div><br></div></span>I’d be very hesitant to introduce this syntax:</div><div><br></div><div><ul class="m_-4753880595475437584m_6043367993829337200m_-5026886634801406416gmail-m_2863118398544756606MailOutline"><li>it’s new syntax, so it comes with a complexity tax (it isn’t naturally obvious what it means for a func to be weak)</li><li>it’s only sugar for the capture of self</li></ul></div></div></blockquote></span><div>it might cover well over 90% of use cases (by my "pessimistic" estimate)... if someone has a quick way to scan and analyse, say, github swift sources we may even know that current percentage number of real life usage.</div><span><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 style="word-wrap:break-word;line-break:after-white-space"><div><ul class="m_-4753880595475437584m_6043367993829337200m_-5026886634801406416gmail-m_2863118398544756606MailOutline"><li>it doesn’t transpose well to local closures</li></ul></div></div></blockquote><div><br></div></span><div>the last one - maybe not. follow me:</div><div><br></div><div>let closure = { [weak self, bar] in ... }</div><div><br></div><div>which today can be written as: <br></div><div><br></div><div>let closure = { [weak self, bar] () -> Int in ... } // full form</div><div><br></div><div>or as:</div><div><br></div><div><div>let closure: () -> Int = { [weak self, bar] in ... } // full form</div></div><div><br></div><div><div>which allows this change:<br></div></div><div><br></div><div>let closure: [weak self, bar] () -> Int = { ... } // full alt form</div><div><br></div><div>or in alternative form:</div><div><br></div><div><div>let closure: weak () -> Int = { [bar] in ... } // short hand form</div></div><div><br></div><div>same can be with functions:</div><div><br></div><div>func fn() -> Int { [weak self, bar] in ... } // full form</div><div><br></div><div>weak func fn() -> Int { [bar] in ... } // short hand form</div><div><br></div><div>the two capture attributes will in practice be "close" to each other:</div><div><br></div><div><div>weak func fn() {</div><div> [bar] in</div><div> ....</div><div>}</div></div><div><br></div><div>and in majority of cases there will be only weak self:</div><div><br></div><div><div>weak func fn() {</div><div> ....<br></div><div>}</div></div><div><br></div><div>Mike</div><div><br></div></div></div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div></div></blockquote><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></span><br></div></blockquote></div></div></div></div></div></div></blockquote></div><br></div>