www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - LDC2 1.9.0 beta 1 bug

reply Shachar Shemesh <shachar weka.io> writes:
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.


LDC - the LLVM D compiler (1.9.0-beta1):
   based on DMD v2.079.1 and LLVM 6.0.0
   built with LDC - the LLVM D compiler (1.9.0-beta1)
   Default target: x86_64-unknown-linux-gnu
   Host CPU: broadwell
   http://dlang.org - http://wiki.dlang.org/LDC

Shachar
Oct 04 2018
next sibling parent Nemanja Boric <dlang nemanjaboric.com> writes:
On Thursday, 4 October 2018 at 12:51:27 UTC, 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.

 [...]


I'm pretty sure I saw an issue in bugzilla few weeks ago... Found 
it:

https://issues.dlang.org/show_bug.cgi?id=19057
Oct 04 2018
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 04 2018
prev sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 4 October 2018 at 12:51:27 UTC, Shachar Shemesh 
wrote:

 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 wrote it yourself: f!()(true, 'S')
Oct 05 2018
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 10/5/18 5:41 AM, Kagamin wrote:

 On Thursday, 4 October 2018 at 12:51:27 UTC, Shachar Shemesh wrote:

 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 wrote it yourself: f!()(true, 'S')


This is a terrible workaround. It looks OK with no vararg parameters, 
but lousy if you have any.

i.e.:

f(arg1, arg2, arg3, true, 'S')

becomes:

f!(typeof(arg1), typeof(arg2), typeof(arg3))(arg1, arg2, arg3, true, 'S');

-Steve
Oct 05 2018