In what order static if conditions are evaluated?

[1100110]

On 03/28/2013 07:04 AM, deadalnix wrote:
> On Thursday, 28 March 2013 at 11:52:26 UTC, Don wrote:
>> On Thursday, 28 March 2013 at 11:29:49 UTC, Artur Zawłocki 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
>>
>> Yes, it currently evaluates it top to bottom. An algorithm has been
>> discussed which would remove that restriction; your example would then
>> compile. It's difficult to implement though. It has to deal with
>> paradoxes:
>>
>> static if (!is(typeof(x)) int y = 1;
>> static if (!is(typeof(y)) int x = 1;
>>
>> Who wins?
>
> Current already have to deal with paradoxes.

Does the current *implementation* have to deal with paradoxes, or do the 
current *users*?  =P

But no serious question. I'm curious.