[swift-evolution] Proposal: Always flatten the single element tuple

[Xiaodi Wu]

On Wed, Jun 7, 2017 at 07:40 Stephen Celis <stephen.celis at gmail.com> wrote:

> > On Jun 7, 2017, at 8:27 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> > 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.
>
> 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.


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.

> An arbitrary argument list cannot be represented as a tuple. For example,
> tuples cannot have elements of variadic type or inout type.
>
> Modifiers like throws/inout/@escaping affect the body of the function and
> are arguably erasable in the data structure itself.


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.

Variadic tuples are disallowed but not an impossible concept (and
> supporting them hasn't been ruled out as far as I can remember).
>
> > Slow, and especially inconsistently slow, performance fits the
> definition of unreliable, wouldn’t you agree?
>
> Again, trade-offs and openness to exploring better solutions.
>
> > They are not.
>
> Other than the function body modifiers, how are they not?


Literally, they are not the same, neither in syntax, nor in the way they
are modeled by the compiler.

Stephen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/916f924b/attachment.html>