On 28/10/2015 4:29 PM, tsbockman wrote:
I would say none, since *the template* contains no unreachable code, and
the compiler can easily trim unreachable code from any *instantiation*
which needs it, without bothering me about it.
If it's unreachable or not depends on what the template is instantiated
with, there is no clear concept of unreachable code without knowing the
template parameters.
bool func(T)(T value) if (isUnsigned!T)
{
if (value < 0)
return true;
return false;
}
Here the first return is definitely dead code for any instantiation, but
to know this the compiler would have to reverse-engineer properties from
the template constraints, which is not generally possible.
I would only be interested in a warning if the compiler wasn't able to
trim the dead code, but as far as I can tell the only case in which the
compiler doesn't trim it, is the case where it doesn't realize it's
unreachable - in which case it can't warn me, either.
Well of course...
It's not intended as a simplification for people who can't handle the
true complexity of templates - the difference is philosophical. It's a
recognition of the fundamental unity of run-time and compile-time
computation, the same idea which motivates CTFE.
IIRC it's intended to avoid scaring people off reading TDPL by avoiding
the work 'template'.
If most people actually *want* these warnings, then great - there's no bug.
But, if most find the warnings conflict with how they want to use
templates, as I do - why not just change it?
I don't want these warnings, so I don't generally build with warnings
enabled.
The "reality" of D templates is whatever the D community chooses to make
it, subject to technical feasibility.
As one of the core compiler devs, I'm saying it sounds infeasible. I
don't think either of your suggested solutions are implementable.
Templates just do not work that way.
> 1. Defer "not reachable" warnings until compilation has been
> completed, and only issue the warning if *all* instantiations of the
> statement were unreachable.
The exact set of instantiations depends on the current module being
compiled, so module A can still get an unreachable code warning even if
in an instantiation from module B the code is reachable.
> 2. For semantic analysis purposes, first instantiate each template
> using dummy parameters with the widest possible VRP ranges. Only
> statements found to be "not reachable" in this dummy run should
> actually generate warnings.
Will not work with compile-time introspection.
In some trivial cases code can be found to be unreachable without doing
semantic analysis, and therefore can be done before template
instantiation. Being limited, I doubt this is of much value.
