On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu wrote:
> Does anyone else find this annoying? https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei

Please no. I'd argue that this brings more confusion than readibility. Imagine reading more complicated code with this. You have to do control flow analysis on if-block to determine whether code outside of if block is included in compilation. Doesn't sound good for reading, does it.

Imagine explaining static if block rules to new people. "Well static if works this way, except it doesn't create scope. Also, we have this another special rule, where we create else blocks implicitly if all paths in static-if block return early. This saves you writing six characters and an intendation level."

Also - metaprogramming. You don't know the control flow of whatever you may be printing in a mixin, or having as a parameter in a template. Making such code even more difficult to analyze.

On Sunday, 26 June 2016 at 21:14:16 UTC, QAston wrote:
> Also - metaprogramming. You don't know the control flow of whatever you may be printing in a mixin, or having as a parameter in a template. Making such code even more difficult to analyze.

Also, this couples runtime control flow with conditional compilation. Those are orthogonal and imo should be kept that way. For me, that's least surprising behavior.

On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/24/16 1:15 PM, Steven Schveighoffer wrote:
> > The problem that hasn't been made clear is, why can't you just write:
> >
> > static if(condition)
> > {
> >
> >     ... // some code
> >     return;
> >
> > }
> >
> > // some more code
> >
> > And the answer is, I'm guessing, bug 14835 -- misguided "unreachable statement" warnings.
> >
> > Should we mark your bug as a duplicate?
>
> Sorry, the problem is that the code doesn't compile at all if the static if is false. So I need to insert the "else".
>
> The compiler should not attempt at all to compile the code after the static if.

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.

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).

- Jonathan M Davis

On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
> We are talking about early returns (checking for something and
> returning as soon as possible) which are a well-known and efficient
> way to reduce indentation levels and increase modularity. You can't
> come and say "What? You want it to work? Man, you should have thought
> your code better!": the very reason this subject is discussed is to
> allow people to deal with indentation levels!

I didn't want to sound like that. But my post was unclear. Though, in the example, it looks nice, and I understand one would want such a feature. I think it could be abused in some other cases and make the code less readable.

I had in mind some cross-platform libraries written in C with #if #elif and #endif all other the place (used with compiler switches). And I reckon the current "static if" is a good tool that fits well with the rest of the language to properly mark different sections of code, and have different implementations. The fact it gives another indentation level could be seen as an opportunity to better modularize code (it's what I meant).

So I find that special case (having code after a "static if() {return;}" treated like in the "else" block) a bit unintuitive, and could be prone to bad practice and confusion.

On Monday, 27 June 2016 at 08:16:18 UTC, Claude wrote:
> On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
>> We are talking about early returns (checking for something and
>> returning as soon as possible) which are a well-known and efficient
>> way to reduce indentation levels and increase modularity. You can't
>> come and say "What? You want it to work? Man, you should have thought
>> your code better!": the very reason this subject is discussed is to
>> allow people to deal with indentation levels!
>
> I didn't want to sound like that. But my post was unclear. Though, in the example, it looks nice, and I understand one would want such a feature. I think it could be abused in some other cases and make the code less readable.
>
> I had in mind some cross-platform libraries written in C with #if #elif and #endif all other the place (used with compiler switches). And I reckon the current "static if" is a good tool that fits well with the rest of the language to properly mark different sections of code, and have different implementations. The fact it gives another indentation level could be seen as an opportunity to better modularize code (it's what I meant).
>
> So I find that special case (having code after a "static if() {return;}" treated like in the "else" block) a bit unintuitive, and could be prone to bad practice and confusion.

What's unintuitive about it (real question)? It would make it behave more like a standard if and early returns are very common, well understood and good practice:

void func(int* somepointer) {
    if (somepointer == null)
        return;
    [rest of the code]
}

When seeing such code (which generally leads to cleaner functions) the meaning is quite obvious, I fail to see who would expect static if to behave otherwise. Of course knowing how it works it makes sense that making it work that way isn't easy but it sounds more like a leaky abstraction than something more intuitive to me.

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.

On 27.06.2016 13:05, cym13 wrote:
> On Monday, 27 June 2016 at 08:16:18 UTC, Claude wrote:
>> On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
>>> We are talking about early returns (checking for something and
>>> returning as soon as possible) which are a well-known and efficient
>>> way to reduce indentation levels and increase modularity. You can't
>>> come and say "What? You want it to work? Man, you should have thought
>>> your code better!": the very reason this subject is discussed is to
>>> allow people to deal with indentation levels!
>>
>> I didn't want to sound like that. But my post was unclear. Though, in
>> the example, it looks nice, and I understand one would want such a
>> feature. I think it could be abused in some other cases and make the
>> code less readable.
>>
>> I had in mind some cross-platform libraries written in C with #if
>> #elif and #endif all other the place (used with compiler switches).
>> And I reckon the current "static if" is a good tool that fits well
>> with the rest of the language to properly mark different sections of
>> code, and have different implementations. The fact it gives another
>> indentation level could be seen as an opportunity to better modularize
>> code (it's what I meant).
>>
>> So I find that special case (having code after a "static if()
>> {return;}" treated like in the "else" block) a bit unintuitive, and
>> could be prone to bad practice and confusion.
>
> What's unintuitive about it (real question)? It would make it behave
> more like a standard if and early returns are very common, well
> understood and good practice:
>
> void func(int* somepointer) {
>      if (somepointer == null)
>          return;
>      [rest of the code]
> }
>
> When seeing such code (which generally leads to cleaner functions) the
> meaning is quite obvious, I fail to see who would expect static if to
> behave otherwise.

Me, because that's what it means to evaluate the condition at compile time and only compiling in the appropriate branch. This is additional and special behaviour and it destroys the orthogonality of 'static if' and 'return'. (I don't feel strongly about the change, but the idea that the new behavior should be expected anyway is flawed.)

> Of course knowing how it works it makes sense that
> making it work that way isn't easy

It's rather easy.

> but it sounds more like a leaky
> abstraction than something more intuitive to me.

My preferred option is to simply add 'static return' to avoid the context-dependence.

On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
> Me, because that's what it means to evaluate the condition at compile time and only compiling in the appropriate branch. This is additional and special behaviour and it destroys the orthogonality of 'static if' and 'return'. (I don't feel strongly about the change, but the idea that the new behavior should be expected anyway is flawed.)
>

Alright, I have to range myself with most here. While I'm all for not warning about unreachable code, I'm opposed to not compiling the rest of the code. This create non orthogonality between static if and control flow analysis, the kind that clearly do not pay for itself.

On Monday, 27 June 2016 at 18:55:48 UTC, deadalnix wrote:
> On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
>> Me, because that's what it means to evaluate the condition at compile time and only compiling in the appropriate branch. This is additional and special behaviour and it destroys the orthogonality of 'static if' and 'return'. (I don't feel strongly about the change, but the idea that the new behavior should be expected anyway is flawed.)
>>
>
> Alright, I have to range myself with most here. While I'm all for not warning about unreachable code, I'm opposed to not compiling the rest of the code. This create non orthogonality between static if and control flow analysis, the kind that clearly do not pay for itself.

Okay, I'm convinced.

On Monday, 27 June 2016 at 11:05:49 UTC, cym13 wrote:
> What's unintuitive about it (real question)? It would make it behave more like a standard if and early returns are very common, well understood and good practice:
>
> void func(int* somepointer) {
>     if (somepointer == null)
>         return;
>     [rest of the code]
> }

From this perspective, you are right. But mixing "return" or "throw" which belong to the "run-time world", and "static if" which is "compile-time" feels wrong somehow to me.

But maybe I'm biased by my C experience. It's like mixing "return" and "#if".

Some other negative responses in this thread may also give a better explanation of what I mean.

The other thing is that, introducing that will not break any code (a priori). But if the change is made, and it turns out to not pay enough or lead to some abuse (more on the readability part), going backward shall introduce code-breakage.

Also, I agree with QAston comments about errors on unreachable code.

Maybe "static return" is a good compromise?...