I dun a DIP, possibly the best DIP ever

[Q. Schroll]

On Wednesday, 22 April 2020 at 13:37:26 UTC, Manu wrote:
> On Wed, Apr 22, 2020 at 11:35 PM rikki cattermole via 
> Digitalmars-d < digitalmars-d at puremagic.com> wrote:
>
>> On 23/04/2020 1:22 AM, Steven Schveighoffer wrote:
>> > On 4/22/20 8:19 AM, rikki cattermole wrote:
>> >> Change it to something like .unpackSequence instead of ... 
>> >> and I would be happy.
>> >
>> > unpackSequence is a valid identifier. That would be a 
>> > breaking change. Plus it would be less obvious. If anything 
>> > it would have to be unpackSequence!(expr).
>> >
>> > Plus there is precedence with C++ for using ...
>> >
>> > And it makes intuitive sense -- you define tuples with T...
>> >
>> > -Steve
>>
>> Yeah.
>>
>> But it also has precedence with type properties such as 
>> mangleof instead of the approach C took with sizeof and 
>> friends.
>>
>> Right now we use it in parameters, adding it to the argument 
>> side with a completely different meaning ugh.

You can distinguish "Types... params" from "Type[] params..." by 
where the dots are.
In contrast to C and C++, D has a very strong principle that 
everything after the parameter (or declared variable) is not part 
of the type. So in the latter case, the dots clearly don't belong 
to the type.

> I feel it's a perfectly natural expansion of the existing 
> meaning. I'm 300% happy with the syntax personally, I will have 
> a tantrum if you take it away from me.

The syntax is perfectly fine for me. Don't be distracted by a 
single opinion. The ... token currently can only be used in (both 
template and function) parameter declarations (and `is` 
expressions where they are kind of the same as template 
parameters). You're introducing it in an expression and/or 
type-expression context which seems to be fine, but very 
technically, it's not. There's one example where it clashes: 
Type-safe variable argument functions that omit their last 
parameter's name.

One thing I want to mention: Let Ts be the type sequence int, 
long, double[]; then

     void f(Ts[]...);

becomes ambiguous. It could mean (by the new proposal)

     void f(int[] __param_0, long[] __param_1, double[][] 
__param_2);

or (by the current language rules)

     void f(int __param_0, long __param_1, double[] __param_2...);

I'm pointing it out, because it is theoretically a breaking 
change with silent change of behavior. I doubt that any code base 
uses that pattern purposefully since it is extremely awkward and 
shouldn't make it through any code review.