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

[Xiaodi Wu]

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

> > 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.


This is an issue that’s coming up on this list with alarming frequency:
meta-debates on what is even in scope for consideration. Reversing five or
six proposals as well as a decision taken prior to Swift 2 is certainly not
“perfectly valid.” Simply, the ship has long sailed.

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).


Those are enums, which were aligned with argument lists instead of tuples
in yet another proposal, SE-0155.

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


Having the compiler perform reliably is the most basic of user ergonomics,
wouldn’t you say?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170607/8888c589/attachment.html>