On 6/24/16 1:54 PM, Andrei Alexandrescu 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".

Even with this, I still didn't understand. Now with your example in the bug report, it's clear. Reproducing here:

void fun(T)(T obj)
{
    static if (!hasMember(T, "gun")) throw new Exception("No gun");
    obj.gun;
}

Call with something that doesn't have a gun member, and even without the reachability warnings (no -w switch), it doesn't compile. However, with an else clause, it would compile.

> The compiler should not attempt at all to compile the code after the
> static if.

Right.

-Steve

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

I made a proposal for this. Yes it is very annoying.

On Friday, 24 June 2016 at 15:43:58 UTC, Stefan Koch wrote:
> To elaborate:
>  This requires control-flow analysis over all static if branches,
>  to find and very one special case which we treat specially.
>

No.

This require to put a maybe reachable flag in some position int the code (namely, after the static if). It is already done, for instance for switch statements.

On Friday, 24 June 2016 at 18:27:07 UTC, Steven Schveighoffer wrote:
>
> Even with this, I still didn't understand. Now with your example in the bug report, it's clear. Reproducing here:
>
> void fun(T)(T obj)
> {
>     static if (!hasMember(T, "gun")) throw new Exception("No gun");
>     obj.gun;
> }
>
> Call with something that doesn't have a gun member, and even without the reachability warnings (no -w switch), it doesn't compile. However, with an else clause, it would compile.
>

It should be (!hasMember!(T, "gun"))

But otherwise, yes, it seems unintuitive to require the else statement. Your point about types not having the gun member failing to compile is what I found confusing. By contrast, when the type has a gun member, it compiles fine. I changed it to return obj.gun and it was fine. So I wouldn't characterize this as a situation where the code below is ignored. I would characterize it as code that should be ignored is otherwise compiled.

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. introduce `final static if` or something, but don't do this with `static if` itself. it makes special case `static if` (one more special deviation to remember, oh, noes), and DMD interproc analysis is non-existing, so `static if (...) { functionThatAlwaysThrow(); }` would fail. and even if it wouldn't, it is still bad, as now i have to guess if that function "never return" or no.

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

What I think about enchancement of static if is that it could be interesting to have `elif` keyword like in Python, so instead of
static if (...)
{

}
else static if(...)
{

}
else static if(...)
{

}
else
{

}

I could write shorter:

static if (...)
{

}
elif (...)
{

}
elif(...)
{

}
else
{

}

In other hand it maybe not got idea to have multiple syntax just for the same think. But we already have multiple syntax for template constraints
template AA (T: int) {}
or
template AA(T) if ( is( T: int ) ) {}

And also shorthand for template using *alias* was added recently:

alias AA(T) = ...

So my idea could survive too.. :) Bad thing here is adding the new keyword, but I don't think that people using word `elif` for names of their variables or functions, if they don't write Python parser of course :)

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

My 2 cents. I don't find that annoying at all. It's perfectly normal IMHO.

It may introduce an additional indentation level for the second part, but I reckon it is normal to have those 2 instruction blocks at the same level. If we were to introduce a new keyword for "static if else", why not do the same for the run-time "if else" (to be coherent)?

And, if some code have too many indentation levels, than it probably means it should be better modularized, hence I'd suggest to split it in several sub-functions, it will be more readable/maintainable.

On Saturday, 25 June 2016 at 10:19:47 UTC, Claude wrote:
> And if some code have too many indentation levels, than it
> probably means it should be better modularized, hence I'd suggest to split it in several sub-functions, it will be more readable/maintainable.

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!

On Saturday, 25 June 2016 at 10:19:47 UTC, Claude wrote:
> 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
>
> My 2 cents. I don't find that annoying at all. It's perfectly normal IMHO.
>
> It may introduce an additional indentation level for the second part, but I reckon it is normal to have those 2 instruction blocks at the same level. If we were to introduce a new keyword for "static if else", why not do the same for the run-time "if else" (to be coherent)?
>
> And, if some code have too many indentation levels, than it probably means it should be better modularized, hence I'd suggest to split it in several sub-functions, it will be more readable/maintainable.

I think if we want we could also add `if else` for run-time if too. In D we have wide usage of CT features and particularly `static if`. It becomes annoying and too verbose to write `else static if` when I have multiple branches, so I was thinking for some time to have `elif` keyword. In this case it would be enough to write static just one time at the beginning of `static if`. Compiler could understand that `elif` belongs to this exact `if` or `static if` that was before it.

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 think less.

sorry.