LDC2 1.9.0 beta 1 bug

[Steven Schveighoffer]

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/myuhmpfygyufxpucvuoh@forum.dlang.org