<div><br><div class="gmail_quote"><div>On Wed, Jun 7, 2017 at 07:16 Stephen Celis <<a href="mailto:stephen.celis@gmail.com">stephen.celis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jun 7, 2017, at 2:01 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> Those are enums, which were aligned with argument lists instead of tuples in yet another proposal, SE-0155.<br>
<br>
Can you clarify? I wasn't referring to enums, and SE-0155 starts by talking about single enum cases with multiple associated values being represented by a tuple.</blockquote><div><br></div><div>Swift package descriptions make extensive use of enums. For example, .target(...) is an enum case with an associated value, unless I’m mistaken. I too got the order of “dependencies” and “path” reversed the other day; if enum associated values were tuples, then it would not have mattered. I assume this is what you were referring to above.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The root values of tuples and structs are product types while enums are sum types. In general, anything with multiple configurable values at the same time are representable by tuples, and argument lists are no exception.</blockquote><div><br></div><div>An arbitrary argument list cannot be represented as a tuple. For example, tuples cannot have elements of variadic type or inout type.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Having the compiler perform reliably is the most basic of user ergonomics, wouldn’t you say?<br>
<br>
Can you clarify what you mean by "reliably"? My understanding was the compiler performed reliably, but more slowly, with more tech debt.</blockquote><div><br></div><div>Slow, and especially inconsistently slow, performance fits the definition of unreliable, wouldn’t you agree?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regardless, why not explore paths that improve both and aren't trade-offs?<br>
<br>
The separation of argument lists and tuples was approached in a very specific way to eliminate a very specific ambiguity, but the data structures are the same.</blockquote><div><br></div><div>They are not.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Susan's proposal is an elegant step towards fixing some of the issues we've been having while specifically preventing previous ambiguities.<br>
<br>
Stephen<br>
<br>
</blockquote></div></div>