<div dir="ltr"><div dir="ltr">On Sat, May 9, 2020 at 3:15 AM Q. Schroll 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 Wednesday, 22 April 2020 at 13:37:26 UTC, Manu wrote:<br>
> On Wed, Apr 22, 2020 at 11:35 PM rikki cattermole via <br>
> Digitalmars-d < <a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
>> On 23/04/2020 1:22 AM, Steven Schveighoffer wrote:<br>
>> > On 4/22/20 8:19 AM, rikki cattermole wrote:<br>
>> >> Change it to something like .unpackSequence instead of ... <br>
>> >> and I would be happy.<br>
>> ><br>
>> > unpackSequence is a valid identifier. That would be a <br>
>> > breaking change. Plus it would be less obvious. If anything <br>
>> > it would have to be unpackSequence!(expr).<br>
>> ><br>
>> > Plus there is precedence with C++ for using ...<br>
>> ><br>
>> > And it makes intuitive sense -- you define tuples with T...<br>
>> ><br>
>> > -Steve<br>
>><br>
>> Yeah.<br>
>><br>
>> But it also has precedence with type properties such as <br>
>> mangleof instead of the approach C took with sizeof and <br>
>> friends.<br>
>><br>
>> Right now we use it in parameters, adding it to the argument <br>
>> side with a completely different meaning ugh.<br>
<br>
You can distinguish "Types... params" from "Type[] params..." by <br>
where the dots are.<br>
In contrast to C and C++, D has a very strong principle that <br>
everything after the parameter (or declared variable) is not part <br>
of the type. So in the latter case, the dots clearly don't belong <br>
to the type.<br>
<br>
> I feel it's a perfectly natural expansion of the existing <br>
> meaning. I'm 300% happy with the syntax personally, I will have <br>
> a tantrum if you take it away from me.<br>
<br>
The syntax is perfectly fine for me. Don't be distracted by a <br>
single opinion. The ... token currently can only be used in (both <br>
template and function) parameter declarations (and `is` <br>
expressions where they are kind of the same as template <br>
parameters). You're introducing it in an expression and/or <br>
type-expression context which seems to be fine, but very <br>
technically, it's not. There's one example where it clashes: <br>
Type-safe variable argument functions that omit their last <br>
parameter's name.<br>
<br>
One thing I want to mention: Let Ts be the type sequence int, <br>
long, double[]; then<br>
<br>
     void f(Ts[]...);<br>
<br>
becomes ambiguous. It could mean (by the new proposal)<br></blockquote><div><br></div><div>Does it though?</div><div>I don't think function declarations accept an expression in the argument list... they are declarations.</div><div><br></div><div>Otherwise you'd be able to specify a function like:</div><div>  void f(10 + 1, Enum.key, nullptr);</div><div><br></div><div>I don't think my DIP interacts with function declarations.</div></div></div>