<div dir="ltr"><div dir="ltr">On Fri, Apr 24, 2020 at 11:00 PM Nick Treleaven via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Friday, 24 April 2020 at 08:04:29 UTC, Walter Bright wrote:<br>
> On 4/24/2020 1:03 AM, Walter Bright wrote:<br>
>> On 4/24/2020 12:10 AM, Manu wrote:<br>
>>>    alias Tup = AliasSeq!(0, 2, 3);<br>
>>>    void fun(int);<br>
>>>    fun(Tup);  // scalar argument receives tuple, it can <br>
>>> expand, so: fun(0), fun(1), fun(2)<br>
>> <br>
>> Write it as:<br>
>> <br>
>>      Tup.fun();<br>
><br>
> Incidentally, belay that. That will currently produce: fun(0, <br>
> 2, 3);<br>
<br>
This syntax is an unfortunate inconsistency with your proposal, <br>
but how often is variadic UFCS used ATM? Its existence has been <br>
pointed out in a NG reply before (I think by Timon), but it <br>
seemed to surprise people. Perhaps it could be deprecated - use <br>
fun(Tup) instead. The latter is more intuitive as people tend to <br>
think UFCS is for the first argument, not multiple arguments. The <br>
spec doesn't seem to suggest variadic UFCS is supported:<br>
<br>
<a href="https://dlang.org/spec/function.html#pseudo-member" rel="noreferrer" target="_blank">https://dlang.org/spec/function.html#pseudo-member</a><br>
<br>
> Of course,<br>
><br>
>     fun(1, Tup);<br>
><br>
> cannot be rewritten in this way<br>
<br>
AliasSeq!(1, Tup).fun(); // fun(1); fun(0); fun(2); fun(3);<br></blockquote><div><br></div><div>I pointed out earlier, and I'll point out again, that Walter's proposal can not be applied to ANY parameter lists, because overloading and possibility for hijacking.<br></div><div><br></div><div>  int fun(int);</div><div>  fun(Tup);  -> 

fun(Tup[0]), fun(Tup[1]), fun(Tup[2])

</div><div><br></div><div>This looks intuitive, but then someone adds:</div><div><br></div><div>  void fun(int, int, int);</div><div><br></div><div>Or maybe it was already there...</div><div>So, a 2 or >=4 len tuple could expand, but a 3-len tuple would call the 3-arg overload.</div><div>What if the function has variadic args?</div><div>Hijacking possibility just wipes this whole thing off the table.</div><div><br></div><div>The ambiguities in Walter's suggestion are impossible to reconcile in a uniform and satisfying way. That's exactly why I moved away from that idea and towards an explicit expression. It's the only way.</div></div></div>