I dun a DIP, possibly the best DIP ever

[Walter Bright]

On 4/24/2020 12:10 AM, Manu wrote:
> Your idea all falls over anywhere it encounters variadic args, or potential for 
> overloads though. Without an explicit expression, the only way forward is to 
> preserve existing D semantics (or it's a radically breaking change), and that 
> will severely narrow the applicability of this proposal.
> 
> Consider this:
> 
>    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();

Of course,

     fun(1, Tup);

cannot be rewritten in this way, but then a rationale will be necessary as to 
why it must be written as func(1, Tup) instead of fun(Tup, 1).


> This same principle argument applies to templates which may receive variadic 
> arguments.
> It weakens the value in my DIP by a huge amount to forego the explicit syntax 
> designed specifically to handle the resolution of ambiguous expressions.

Please enumerate examples, along with an explanation of why they are compelling 
and why it is unreasonable to do another way. (One such other way would be using 
static foreach.)


> This doesn't rule out your proposition that `Tup + 10` can (and probably should) 
> work though.

At least we agree on something :-)

On a philosophical point, I am generally opposed to adding syntax just to 
support some unusual cases. I am sure one could come up with examples where the 
... syntax won't work, too. For example, could it work with creating a new tuple 
out of every third tuple member? I'm not looking for a specific answer, but for 
a meta answer of "should we support these operations at all with special syntax"?

My predisposition is towards simple building blocks that can be combined to 
derive complex behaviors, not complex building blocks that we try to bash into 
simple behaviors. Simple things like applying the existing behaviors of array 
operations to tuples. D shouldn't consist of a mass of special rules, but a 
smaller set of rules that can be consistently applied across diverse situations.

We did the same thing with named function arguments - apply the existing rules 
for named struct initializers. It didn't support every behavior people desired, 
but it supported enough that the remainder wasn't particularly significant.