On Friday, 29 March 2013 at 13:54:03 UTC, Timon Gehr wrote:
On 03/29/2013 12:33 PM, "Artur Zawłocki"
<artur.zawlo...@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.
