<div><br><div class="gmail_quote"><div>On Wed, Jun 7, 2017 at 07:40 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 8:27 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
<br>
Enum associated values are isomorphic to tuples. Function arguments are also isomorphic to tuples. You're referring to a specific ordering issue that exists in both enum cases with multiple associated values, functions arguments (like a struct initializer), and tuples.</blockquote><div><br></div><div>I’m not sure what you’re getting at. My point is that tuples currently allow “shuffling” with labels but argument lists do not, and that enum associated values were recently revised to be initialized with an argument list and not a tuple, although that proposal is not fully implemented.</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">
> An arbitrary argument list cannot be represented as a tuple. For example, tuples cannot have elements of variadic type or inout type.<br>
<br>
Modifiers like throws/inout/@escaping affect the body of the function and are arguably erasable in the data structure itself.</blockquote><div><br></div><div>An early proposal moved the placement of inout to reflect the fact that `inout T` is a distinct type from `T`. Escaping vs. non-escaping closures also have type system significance, afaik; this is why `withoutActuallyEscaping` required quite a bit of cleverness to implement and cannot be expressed in Swift itself. In any case, the compiler itself no longer represents argument lists as tuples, and that distinction is fully plumbed through, unless I’m mistaken.</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">
Variadic tuples are disallowed but not an impossible concept (and supporting them hasn't been ruled out as far as I can remember).<br>
<br>
> Slow, and especially inconsistently slow, performance fits the definition of unreliable, wouldn’t you agree?<br>
<br>
Again, trade-offs and openness to exploring better solutions.<br>
<br>
> They are not.<br>
<br>
Other than the function body modifiers, how are they not?</blockquote><div><br></div><div>Literally, they are not the same, neither in syntax, nor in the way they are modeled by the compiler.</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">
Stephen<br>
<br>
</blockquote></div></div>