On Fri, Apr 24, 2020 at 11:00 PM Nick Treleaven via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On Friday, 24 April 2020 at 08:04:29 UTC, Walter Bright wrote:
> On 4/24/2020 1:03 AM, Walter Bright wrote:
>> On 4/24/2020 12:10 AM, Manu wrote:
>>>    alias Tup = AliasSeq!(0, 2, 3);
>>>    void fun(int);
>>>    fun(Tup);  // scalar argument receives tuple, it can
>>> expand, so: fun(0), fun(1), fun(2)
>>
>> Write it as:
>>
>>      Tup.fun();
>
> Incidentally, belay that. That will currently produce: fun(0,
> 2, 3);

This syntax is an unfortunate inconsistency with your proposal,
but how often is variadic UFCS used ATM? Its existence has been
pointed out in a NG reply before (I think by Timon), but it
seemed to surprise people. Perhaps it could be deprecated - use
fun(Tup) instead. The latter is more intuitive as people tend to
think UFCS is for the first argument, not multiple arguments. The
spec doesn't seem to suggest variadic UFCS is supported:

https://dlang.org/spec/function.html#pseudo-member

> Of course,
>
>     fun(1, Tup);
>
> cannot be rewritten in this way

AliasSeq!(1, Tup).fun(); // fun(1); fun(0); fun(2); fun(3);

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.

  int fun(int);
  fun(Tup);  ->  fun(Tup[0]), fun(Tup[1]), fun(Tup[2])

This looks intuitive, but then someone adds:

  void fun(int, int, int);

Or maybe it was already there...
So, a 2 or >=4 len tuple could expand, but a 3-len tuple would call the 3-arg overload.
What if the function has variadic args?
Hijacking possibility just wipes this whole thing off the table.

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.