In what order static if conditions are evaluated?

[Timon Gehr]

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?

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

> 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.)