On 10/4/18 8:51 AM, Shachar Shemesh wrote:
I got this as a report from a user, not directly running this, which is
why I'm not opening a bug report.
Consider the following function:
void f(ARGS...)(ARGS args, bool arg1 = true, char arg2 = 'H');
Now consider the following call to it:
f(true, 'S');
Theoretically, this can either be calling f!()(true, 'S') or f!(bool,
char)(true, 'S', true, 'H');
Under 1.8.0, it would do the former. Under 1.9.0-beta1, the later.
Why is this a bug?
Two reasons. First, this is a change of behavior.
More to the point, however, expanding the call to the second form means
that I can *never* supply non-default values to arg1 and arg2.
You are correct that it's a change in behavior. Johan brought this up
earlier when the release happened [1], and I agree with both you and him
that the behavior change requires at least a deprecation cycle.
But it doesn't seem to be getting traction with the people who have made
the decision in the first place (and Walter simply said to post a bug
report, which has happened).
I will point out a couple things:
1. Yes you can supply non-default values to arg1 and arg2, you just
can't use ifti. I can't begin to describe how useless this is.
2. The problem with the original behavior is that you couldn't *actually
use* the default parameters. In other words, this doesn't compile:
f();
So technically, it was simply an error to provide default parameters in
a template variadic (the explicit instantiation workaround was allowed,
but again, useless).
My argument in the bug report is that the whole reason it was added (to
allow file and line numbers to be runtime parameters in exception
constructors) is more correctly fixed by fixing another issue,
https://issues.dlang.org/show_bug.cgi?id=18919, and the expected way
that default parameters behave should be implemented instead. Both the
old way and the new way have large inconsistency problems.
-Steve
[1] https://forum.dlang.org/post/myuhmpfygyufxpucv...@forum.dlang.org
