<div dir="ltr">I would defend turning tuples into structs (change from structural type to nominal type). This is a much better story for programmers, compare the two stories:<div><ol><li>Tuples are just syntax sugar for simple structs.</li><li>Tuples are sort of like structs but there is a list of things tuples can do that structs can&#39;t and a list of things structs can do and tuples can&#39;t.<br></li></ol>I think unification can be achieved with some name mangling (Chris Lattner noted this previously - I am just spelling out one scheme), e.g.:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">// var a = (zero: 0, one: 1)<br>public struct Tuple_zero_Int_one_Int { // Mangle name.<br>    public var zero: Int<br>    public var one: Int<br>}<br>var a = Tuple_zero_Int_one_Int(zero: 0, one: 1)<br>// a.0 = -1<br>a.zero = -1<br><br>// var b = (0, 1)<br>public struct Tuple_0_Int_1_Int { // Mangle name.<br>    public var _0_: Int // Unique name.<br>    public var _1_: Int // Unique name.<br>}<br>var b = Tuple_0_Int_1_Int(_0_: 0, _1_: 1)<br>// a = b<br>a = Tuple_zero_Int_one_Int(zero: b._0_, one: b._1_)<br></blockquote><br><div>Implicit in the above transformation is:</div><div><ol><li>struct and tuple have the same memory layout.</li><li>`.0` access the 1st stored property of a struct, `.1` the 2nd, etc.</li></ol></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 22 November 2017 at 18:02, David Hart via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><span class=""><br><blockquote type="cite"><div>On 22 Nov 2017, at 07:54, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>&gt; wrote:</div><br class="m_-366243897945647700Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Nov 21, 2017, at 10:48 PM, David Hart &lt;<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>&gt; wrote:</div><br class="m_-366243897945647700Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class="m_-366243897945647700Apple-interchange-newline"><br>On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br><div><br><blockquote type="cite"><div>On Nov 21, 2017, at 10:37 PM, Chris Lattner &lt;<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>&gt; wrote:</div><br class="m_-366243897945647700Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">On Nov 21, 2017, at 9:25 PM, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>&gt; wrote:<br><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Or alternatively, one could decide to make the generics system *only and forever* work on nominal types, and make the syntactic sugar just be sugar for named types like Swift.Tuple, Function, and Optional.  Either design could work.</div></div></blockquote><br></div><div>We don’t have a way to make it work for function types, though, because of parameter-passing conventions. Well, assuming we don’t invent something that allows:</div><div><br></div><div><span class="m_-366243897945647700Apple-tab-span" style="white-space:pre-wrap">        </span>Function&lt;Double, inout String&gt;</div><div><br></div><div>to exist in the type system. Tuple labels have a similar problem.</div></div></div></blockquote><br></div><div>I’m totally aware of that and mentioned it upthread.<span class="m_-366243897945647700Apple-converted-space"> </span></div></div></div></blockquote><div><br></div><div>Eh, sorry I missed it.</div><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div> There are various encoding tricks that could make this work depending on how you want to stretch the current generics system…</div></div></div></blockquote><br></div><div>I think it’s straightforward and less ugly to make structural types allow extensions and protocol conformances.</div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Can somebody explain to me what is less ugly about that? I would have naturally thought that the language would be simpler as a whole if there only existed nominal types and all structural types were just sugar over them.</div></div></blockquote></div><br><div>See Thorsten’s response with, e.g.,</div><div><br></div><div><span class="m_-366243897945647700Apple-tab-span" style="white-space:pre-wrap">        </span>      Function&lt;Double, InoutParam&lt;String&gt;, Param&lt;Int&gt;&gt;</div><div><br></div><div>which handles “inout” by adding wrappers around the parameter types (which one would have to cope with in any user of Function), but still doesn’t handle argument labels. To handle argument labels, we would need something like strings as generic arguments. We’d also need to handle calling conventions and anything else we invent for function types.</div></div></div></blockquote><div><br></div></span><div>Oh ok, I get. The ugliness comes from trying to shoehorn structural types into nominal types.</div><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><span class="m_-366243897945647700Apple-tab-span" style="white-space:pre-wrap">        </span>- Doug</div><div><br></div><div><br></div></div></div></blockquote></div><br></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>