Comment #0 by bruno.do.medeiros+deebugz — 2008-07-05T07:20:00Z
D accepts variadic parameters that are not array types, such as this:
void foo(int bar ...)
However this does not make much sense, since the bar parameter is not variadic, the function can only be called with one argument.
To avoid confusion, it would be an improvement to disallow non-array parameter types as variadic parameters.
An alternatice sugestion, would be for any variadic parameter to automatically become of the array type of the type declared in the signature. Such that in:
void foo(int bar ...)
then typeof(bar) becomes int[]. This behavior would be identical to Java. Also it would allow a further improvement, a more consistent syntax for lazy variadic templates, like this:
void foo(lazy int bar ...)
where typeof(bar) would be int delegate()[]
And we would no longer need the awkward special case where variadic arguments can be converted to delegates, such as with this:
void cond(bool delegate()[] cases ...)
Comment #1 by matti.niemenmaa+dbugzilla — 2008-07-05T14:06:27Z
The advantage is that, given:
class C { int a, b, c; }
void foo(C c...) {}
You can call either:
foo(new C(1, 2, 3));
foo(1, 2, 3);
For primitive types it is indeed useless, though.
Comment #2 by bruno.do.medeiros+deebugz — 2008-07-26T06:06:30Z
(In reply to comment #1)
> The advantage is that, given:
> class C { int a, b, c; }
> void foo(C c...) {}
> You can call either:
> foo(new C(1, 2, 3));
> foo(1, 2, 3);
> For primitive types it is indeed useless, though.
I see. Well then, it becomes an issue of which alternative is better. I still prefer the first one, as I think it's cleaner.
Comment #3 by andrei — 2016-12-22T14:55:33Z
We should reject this during semantic checking.
Comment #4 by dmitry.olsh — 2018-05-15T14:41:16Z
As per Andrei comment, whatever we reject during semantic but don't is a bug.
Comment #5 by robert.schadek — 2024-12-13T17:48:38Z