static if enhancement

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 28 15:38:28 PDT 2016


On Tuesday, June 28, 2016 13:34:48 QAston via Digitalmars-d wrote:
> On Monday, 27 June 2016 at 22:56:41 UTC, Jonathan M Davis wrote:
> > Agreed. The code outside of the static if should be compiled
> > regardless, because it's not part of the static if/else at all
> > and therefore has not been marked as conditionally compilable.
> > But if we don't warn about unreachable code, then the code
> > after the static if can clearly be optimized out because it's
> > unreachable. So, Andrei's code would become legal as long as
> > the only problem with the code after the static if was that it
> > was unreachable.
> >
> > - Jonathan M Davis
>
> The "allow unreachable code" solution has it's own limitations
> compared to implicit-else-block. It doesn't allow varying return
> type and differing declarations in the two blocks.

And IMHO, it shouldn't, because that should only work if the code has been
marked as conditionally compilable, which you do by putting the code within
a branch of the static if. I _really_ don't agree with the idea that code
that is not explicitly marked as conditionally compilable would be treated
as conditionally compilable. And as long as we keep things so that only code
which is explicitly marked as conditionally compilable is conditionally
compilable, then this whole issue devolves to the issue of whether we should
treat unreachable code as an error or not. If we do, then Andrei's code
won't compile (and rightly so IMO), whereas if we decide that we'd be better
off allowing unreachable code, then Andrei's code would happen to compile.
But regardless, I think that the issue should be approached as a question of
whether unreachable code should be allowed and that we should not treat code
as conditionally compilable just because of a return statement in the
conditionally compilable code before it. Such behavior would be inconsistent
and confusing.

So, the question is then whether we should allow unreachable code, and there
are very good reasons for allowing it and very good reasons for not allowing
it. But that discussion is much wider than the case where a static if
happens to return and involves pros and cons which do not necessarily apply
to that particular case.

> I personally like present state of things.

I can certainly live with it, but I'd definitely prefer that we not warn
about unreachable code. There are times when having the compiler complain
about unreachable code can be useful, but in my experience, it just isn't an
issue. If I have unreachable code, I know that it's unreachable, and I don't
need the compiler to tell me about it - and odds are that I'd _like_ for it
to still compile in spite of it being unreachable. I'm frequently forced to
comment out code when debugging when I'd just as soon just throw a return
statement in there and not bother with commenting anything, but the compiler
won't let me. So, personally, I see little value in having the compiler warn
about unreachable code, but I can see why someone would think that it would
be of benefit.

A similar case is unused variables, which we can't treat as warnings or
errors because of stuff like traits, since they declare variables without
using them all the time. Some folks would still like a warning or error
though. It's just that in that case, we decided to let the compiler ignore
them, whereas with unreachable code, we went the other way.

- Jonathan M Davis



More information about the Digitalmars-d mailing list