<div><br><div class="gmail_quote"><div>On Wed, Jun 7, 2017 at 00:39 Stephen Celis <<a href="mailto:stephen.celis@gmail.com">stephen.celis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Jun 7, 2017, at 1:05 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
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.</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).</blockquote><div><br></div><div>Those are enums, which were aligned with argument lists instead of tuples in yet another proposal, SE-0155.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All of these hiccups are the result of compiler optimizations and simplifications that hinder end-user ergonomics.</blockquote><div><br></div><div>Having the compiler perform reliably is the most basic of user ergonomics, wouldn’t you say?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Stephen</blockquote></div></div>