static if enhancement

[QAston via Digitalmars-d]

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.