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

[Xiaodi Wu]

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

> > On Jun 7, 2017, at 2:01 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> > Those are enums, which were aligned with argument lists instead of
> tuples in yet another proposal, SE-0155.
>
> 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.


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.

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.


An arbitrary argument list cannot be represented as a tuple. For example,
tuples cannot have elements of variadic type or inout type.

> Having the compiler perform reliably is the most basic of user
> ergonomics, wouldn’t you say?
>
> Can you clarify what you mean by "reliably"? My understanding was the
> compiler performed reliably, but more slowly, with more tech debt.


Slow, and especially inconsistently slow, performance fits the definition
of unreliable, wouldn’t you agree?

Regardless, why not explore paths that improve both and aren't trade-offs?
>
> 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.


They are not.

Susan's proposal is an elegant step towards fixing some of the issues we've
> been having while specifically preventing previous ambiguities.
>
> Stephen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/6c998424/attachment.html>