On Wed, Jun 7, 2017 at 00:39 Stephen Celis <[email protected]> wrote:
> > On Jun 7, 2017, at 1:05 AM, Xiaodi Wu <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
