> 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
On Wed, Jun 7, 2017 at 00:39 Stephen Celis <email@example.com> wrote:
> On Jun 7, 2017, at 1:05 AM, Xiaodi Wu <firstname.lastname@example.org> wrote:
possible, the end-user and end-use cases suffer along the way.