On Monday, 27 June 2016 at 00:31:39 UTC, Jonathan M Davis wrote:
On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via
Digitalmars-d wrote:
I would think that it's highly unintuitive to think that code
outside of a static if would be treated as part of an else of a
static if just because the static if happens to return at the
end. Certainly, if the code after the static if couldn't
compile if the static if code didn't return, I definitely think
that the code following it needs to be in an else. Really, it
seems to me that this comes down to a complaint about the
compiler producing errors on unreachable code - which is the
sort of thing that I tend to think should not be treated as an
error - _especially_ with how badly it tends to interact with
generic code.
+1
So, as long as the code following the static if is valid
without being in an else for the static if, I'm all for having
the compiler just optimize out everything after the return
without complaining - but if we're going to do that, it really
shouldn't be specific to static ifs. That would be unreasonably
inconsistent IMHO. And I don't think that it's a good idea to
treat code following a static if as if it were in an else just
because of a return statement or break statement or some other
control statement in the static if which would cause the code
after it to be skipped. That would be confusing and
inconsistent IMHO, much as it would be nice to avoid the extra
braces and indentation.
So, if we're going to change things here, I think that the
approach is to stop having the compiler complain about
unreachable code, which I think is very reasonable in light of
how annoying that can get - particularly with generic code -
though I'm sure that some folks will be unhappy about that just
like some folks want the compiler to complain about unused
variables (though we don't do that in part because of how badly
it interacts with various D features - like highly templatized
code - and that's pretty much the main reason that having the
compiler complain about unreachable code is so problematic,
which could be an argument to have it stop complaining about
it).
I'm one of those folks who think that errors about unreachable
code are important and I'm perfectly willing to pay the price of
usually short changes to code to keep things clear. Especially in
generic code, as for me not knowing what's going on is far more
annoying than having to maintain a bit of structure.
That said, when faced with choice between having unreachability
error removed and having a change in the language making every
static if more complex, I definitely prefer having errors removed
and the code being optimized out. Errors can be always added by
external tools. Inconsistencies in the language can't be fixed
externally. The proposed language change brings an inconsistency
for a trivial gain. Ignoring unreachable code is a consistent
change, so in my opinion a much better solution.
