In what order static if conditions are evaluated?

[1100110]

On 03/28/2013 06:29 AM, "Artur Zawłocki" <artur.zawlocki at gmail.com>" wrote:
> Hi,
>
> DMD (I'm using v2.060) seems to evaluate conditions in static if's from
> top to bottom (at least in a given scope). For example, consider the
> following program:
>
> module test;
>
> const bool x = true;
> const bool y = true;
>
> struct S {
>
> static assert(y);
>
> static if(x)
> static const bool y = false;
>
> static if(y)
> static const bool x = false;
> }
>
> 'x' in the first static if condition refers to .x and the static if
> introduces S.y to which 'y' in the second static if refers. 'y' in the
> static assert also refers to S.y and thus the assertion fails:
>
> test.d(8): Error: static assert (y) is false
>
> Now, I guess if the second static if were evaluated first then 'y' in
> the static assert condition would refer to .y and the program would
> compile. Note that dmd evaluates the static assert *after* both static
> if's.
>
> So clearly D program semantics depends on the order static if's and
> static assert's are evaluated. Are there any standard rules here (I
> cannot find anything in Language Reference) or is this behaviour
> implementation dependent?
>
> Artur

It should behave the "same" as a normal if statement.

Except it is evaluated during compile-time and not runtime.

The only different that I know of is that the brackets will not 
introduce a new scope.

string Y;

if(true) {
	string x = "I'm not in the same scope as Y";
}
static if(true) {
	string z = "but I am";
}

that's the only "gotcha" I know of, and I seems quite intuitive once you 
realize why that is the case.



But I can't think of any reason why a compiler would want to mix up the 
static if's....  Sounds malicious to me. =P