https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
I think we need to find a way to change this behavior, and soon. As it stands now, it doesn't make sense, as it's only useful in the __FILE__ and __LINE__ context. It could easily be generalized to fit all contexts, even in a way where the original behavior is valid. I'd flag this as a regression if it were up to me.

The change that allows default parameters to work is reasonable. The change that makes them NEVER match IFTI-passed arguments is very bad and not intuitive.

I'd absolutely expect this to work like anyone would think it should:

Exception genErr(A...)(A args, string file = __FILE__, size_t line = __LINE__)

Exception genSpecificError(string file = __FILE__, size_t line = __LINE)
{
   return genErr(1, 2, 3, file, line);
}

And the workaround is NOT pleasant.

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #9 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to johanengelen from comment #7)
> This did break code at Weka, luckily in non-silent way, but now I probably will have to modify the old compiler to error on these things, to not cause trouble with silently broken code.

I'm curious if there is any reason to have default parameter specification in any of these cases. Given that you could never use the default parameters anyway (you had to specify them all), isn't the fix to just change them all to not have default values?

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #10 from johanengelen@weka.io ---
(In reply to Steven Schveighoffer from comment #9)
> (In reply to johanengelen from comment #7)
> > This did break code at Weka, luckily in non-silent way, but now I probably will have to modify the old compiler to error on these things, to not cause trouble with silently broken code.
> 
> I'm curious if there is any reason to have default parameter specification in any of these cases. Given that you could never use the default parameters anyway (you had to specify them all), isn't the fix to just change them all to not have default values?

Indeed, the fix is trivial. But finding all places to fix it may not be so easy. Perhaps it's not so bad and a regexp search will find them. I was happy to find out that it never really worked.

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #11 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
(In reply to Steven Schveighoffer from comment #8)
> I think we need to find a way to change this behavior, and soon. As it stands now, it doesn't make sense, as it's only useful in the __FILE__ and __LINE__ context. It could easily be generalized to fit all contexts, even in a way where the original behavior is valid. I'd flag this as a regression if it were up to me.
> 
> The change that allows default parameters to work is reasonable. The change that makes them NEVER match IFTI-passed arguments is very bad and not intuitive.
> 
> I'd absolutely expect this to work like anyone would think it should:
> 
> Exception genErr(A...)(A args, string file = __FILE__, size_t line =
> __LINE__)
> 
> Exception genSpecificError(string file = __FILE__, size_t line = __LINE)
> {
>    return genErr(1, 2, 3, file, line);
> }
> 
> And the workaround is NOT pleasant.

Well, having file or line end up being given values just because a string or string and integral value happened to be last in the argument list would arguably be really bad, because then it becomes trivial to screw up the file and line number, whereas if you have to explicitly instantiate the function template to give file and line different values, then we don't have that problem, and in most cases, explicitly passing values for file or line is unnecessary, so arguably the extra annoyance isn't likely to come up often enough to be a big deal.

I confess that I never would have expected parameters to be allowed after variadic arguments though, so the current behavior actually matches up extremely well with what I would have expected the behavior to be if we allow paramters with default arguments after the variadic parameter.

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #12 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Jonathan M Davis from comment #11)
> Well, having file or line end up being given values just because a string or string and integral value happened to be last in the argument list would arguably be really bad, because then it becomes trivial to screw up the file and line number, whereas if you have to explicitly instantiate the function template to give file and line different values, then we don't have that problem, and in most cases, explicitly passing values for file or line is unnecessary, so arguably the extra annoyance isn't likely to come up often enough to be a big deal.

That is already a problem without variadics. For example, if you change the parameters of a non-variadic function to insert a string before the __FILE__ default, now you have code that may still compile even with the old version and not do what it's supposed to do.

Part of the problem for this pattern is that the type of the __FILE__ and __LINE__ parameters are normal types used all over the place (string and size_t). That is not the fault of variadics, but the fault of the pattern. It's why we have things like enums.

The real solution is to make it so you can pass in a converted type with the __FILE__ or __LINE__ as the default, but this doesn't work (see issue 18919). If that was fixed, then we can change all the file/line parameters to something more explicit than string/int. See this relevant discussion: https://forum.dlang.org/post/furtfdpjdeltntvzdixx@forum.dlang.org

> I confess that I never would have expected parameters to be allowed after variadic arguments though, so the current behavior actually matches up extremely well with what I would have expected the behavior to be if we allow paramters with default arguments after the variadic parameter.

But that was never in question. Variadics with trailing parameters was always allowed. It's that if you had default values, the default values were NEVER USED. The problem with the PR that caused all this mess is that it changes the behavior of those parameters when you give it a default, and this was a silent breaking change. If the compiler simply rejected those parameters to begin with, then this would have been less of a problem.

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #13 from johanengelen@weka.io ---
(In reply to Jonathan M Davis from comment #11)
> 
> I confess that I never would have expected parameters to be allowed after variadic arguments though, so the current behavior actually matches up extremely well with what I would have expected the behavior to be if we allow paramters with default arguments after the variadic parameter.

That argument only makes sense iff default arguments are obligatory for
parameters after variadic parameters. But that's not the case, default
arguments are _not_ required and that has been working for a long time.
The current behavior only makes sense in isolation, but breaks when considering
slightly larger scope (i.e. with _and_ without default argument specified).

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #14 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
The current behavior works well with default arguments, because then they never get accidentally matched, whereas IFTI is allowed to match arguments against them, then it becomes trivial to match them accidentally, and if that were the case, I'd argue strongly that putting default arguments on parameters that come after variadic parameters was too error-prone for it to make any sense. At least in the case where there are no default arguments, you always have to provide the arguments, so it's expected. But once you have default arguments, those arguments are no longer expected, and it becomes trivial to think that you're passing an argument that matches the variadic parameters but ends up matching at least one of the parameters after the variadic parameters. The behavior would be fatal for any attempt at something like logging because of how much would accidentally match against __FILE__, but any case where you have parameters with default arguments following varidiac parameters would be very error-prone unless the types involved were extremely unlikely to be passed to the function. I fail to see why having the parameters with default arguments matching with IFTI would ever be desirable. It's just too error-prone.

--

https://issues.dlang.org/show_bug.cgi?id=19057

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--

https://issues.dlang.org/show_bug.cgi?id=19057

--- Comment #15 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dlang.org/issues/4090

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--