On Sat, May 9, 2020 at 3:15 AM Q. Schroll via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
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@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)

Does it though?
I don't think function declarations accept an expression in the argument list... they are declarations.

Otherwise you'd be able to specify a function like:
  void f(10 + 1, Enum.key, nullptr);

I don't think my DIP interacts with function declarations.