In what order static if conditions are evaluated?

1100110 0b1100110 at gmail.com
Thu Mar 28 07:04:57 PDT 2013


On 03/28/2013 08:15 AM, "Artur Zawłocki" <artur.zawlocki at gmail.com>" wrote:
> On Thursday, 28 March 2013 at 11:50:58 UTC, 1100110 wrote:
>> 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.
>
> Why? static if is not a statement at all, it's a 'conditional
> declaration'. And the order in which declarations are processed on the
> top level is not relevant (unless you have static if's, that is), e.g.
> you can have:
>
> static if (a)
> static assert (true);
>
> const bool a = true;
>
> I've just discovered that this is also OK:
>
> static if (S.a)
> static assert (true);
>
> struct S { static if if (true) const bool a = true; }
>

Ah! I see what you're getting at.

I had just assumed getting it right was up to us.  =P


More information about the Digitalmars-d mailing list