In what order static if conditions are evaluated?

[Artur Zawłocki" <artur.zawlocki at gmail.com>]

On Friday, 29 March 2013 at 13:54:03 UTC, Timon Gehr wrote:
> On 03/29/2013 12:33 PM, "Artur Zawłocki" 
> <artur.zawlocki at gmail.com>" wrote:
>> On Thursday, 28 March 2013 at 18:24:19 UTC, Timon Gehr wrote:
>>
>>> (...)
>>> Indeed, the above code should not compile. My upcoming D 
>>> front end
>>> currently reports the following after fixing the grammatical 
>>> mistakes
>>> (For now. The error message text should maybe be improved. 
>>> Ideas
>>> welcome.)
>>>
>>> tt.d:2:32: error: declaration of 'x' smells suspiciously fishy
>>> static if (!is(typeof(y))) int x = 1;
>>>                               ^
>>> tt.d:1:23: note: this lookup should have succeeded if it was 
>>> valid
>>> static if (!is(typeof(x))) int y = 1;
>>>                      ^
>>> tt.d:1:32: error: declaration of 'y' smells suspiciously fishy
>>> static if (!is(typeof(x))) int y = 1;
>>>                               ^
>>> tt.d:2:23: note: this lookup should have succeeded if it was 
>>> valid
>>> static if (!is(typeof(y))) int x = 1;
>>>                      ^
>>
>> Surely it will be fun to work with (though 'this lookup' 
>> message is
>> somewhat confusing)!
>>
>
> Yes. What would be a better message?
>

I don't know.

>>> There are lots of similar analysis order issues without 
>>> static if.
>>> (Luckily, they can be detected well enough conservatively in 
>>> a quite
>>> general way.) The following is a simplified example from my 
>>> test suite:
>>>
>>> class A{ int string; }
>>> template Mixin(string s){
>>>    mixin("alias "~s~" Mixin;");
>>> }
>>> class D: Mixin!({D d = new D; return d.foo();}()){
>>>    int foo(int x){ return 2;}
>>>    string foo(){ return "A"; }
>>> }
>>>
>>> The problem is of course that 'string' has to be resolved in 
>>> order to
>>> compute the parent of 'D'. However, that parent then changes 
>>> the
>>> meaning of 'string' in the subclass scope. Therefore, the 
>>> code is
>>> meaningless.
>>
>> I am lost here. Are 'int string' in A
>
> Yes.
>
>> in and 'int foo(int)' in D
>
> No.
>
>> relevant?
>> Shouldn't this example fail simply because in order to process
>> the declaration of D the compiler needs to instantiate D in 
>> the delegate
>> body?
>
> No, D's parent is not required to be known in order to execute 
> what is in the delegate body.

Knowing the parent of D is not required to create an instance of 
D?

>
>> So this would be similar to:
>>
>>   template Mixin(bool b : true) {
>>     alias Object Mixin;
>>   }
>>   class D: Mixin!(new D == new D) {}
>>
>>
>
> This fails because new D == new D is false. (Otherwise it would 
> work.)

See my comment above.