[Issue 19057] 2.079 changelog variadic template and default arguments

d-bugmail at puremagic.com d-bugmail at puremagic.com
Fri Jul 6 13:33:28 UTC 2018


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

--- Comment #12 from Steven Schveighoffer <schveiguy at 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.

--


More information about the Digitalmars-d-bugs mailing list