On 10/28/15 6:02 AM, Daniel Murphy wrote:
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.

You're not thinking from the user's point of view. It's a statement. I wrote it because I want it to work in certain instantiations. The compiler is incorrectly complaining that it can't be reached, because I can reach it by calling it a different way (easy to prove).

The warning should either be eliminated, or fixed so it's accurate. This reminds me of people adding empty try/catch clauses to Java to shut the compiler up about the checked exceptions.


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'm OK with the compiler giving up and not warning here. This warning is an optimization, and a *warning*, not an error.

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.

As will others who do want warnings, but don't want to deal with the compiler making false accusations :)

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.

What about disabling unreachability detection if a static branch (either explicit or implied by const folding) depends on a template variable?

If we can't fix this, I think we're better off without the warning.

-Steve

Reply via email to