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

[Stephen Celis]

> On Jun 7, 2017, at 1:05 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> This is not what was meant during discussion about re-evaluating SE-0110. Tuples already behave as described, but function argument lists are not tuples and have not been for a very long time: see SE-0029, SE-0066.
> 
> Also, consider SE-0046, which makes possible labels in single-argument argument lists (not possible in tuples), and SE-0060, which prohibits arbitrary reordering (although still possible in tuples). This is to say that the whole direction of Swift since version 2 has been to erase the historical relationship between tuples and argument lists.
> 
> The question is how to accommodate some common use cases for destructuring as a matter of syntactic sugar after having carefully distinguished argument lists and tuples in the compiler, which is a given, not how to roll back a change that was settled in 2011, by Chris’s telling.

As one of many who is directly affected and wants resolution, I think the discussion of re-evaluating SE-0110 most certainly expands to these earlier decisions. While Swift has moved in the direction of distinguishing tuples and argument lists in decidedly different ways, I think it's perfectly valid to consider the alternative: a simpler and equally-valid solution: flattened tuples that are isomorphic to argument lists.

Argument labels certainly complicate semantics, but we still erase tuple labels in general use to this day. Meanwhile, prohibited arbitrary reordering remains complicated (I just recently worked with an SPM module that advertised instructions the compiler disallowed, and it took awhile to find the correct, compiler-allowed ordering while troubleshooting confusing, compiler-driven error messaging).

All of these hiccups are the result of compiler optimizations and simplifications that hinder end-user ergonomics.

Again: while I can appreciate making the compiler as simple and strict as possible, the end-user and end-use cases suffer along the way.

Stephen