question...

[Aziz K.]

Marcin Kuszczak wrote:
> Thanks but explanation. But I think that somethink is wrong here anyway.
> Please see first example. 'A' is also not expression, but it compiles
> properly. Maybe it would not be a big problem to extend typeof in such a
> way that it can accept types also.
>

This is the example:
class A {}
static assert(is( typeof(new A) == typeof(A)) ); // 1

The 'A' in typeof is an expression. Of course a human reader can see that  
it actually is a type (class A), but to a D parser it is an "Expression"  
because that's what the grammar rules say. Only when the semantic pass is  
started, identifiers can be resolved to the symbol they refer to, which  
could be a variable, a function, a class, a type etc.
That means, what an identifier in an Expression actually is can only be  
determined in the semantic phase. But on the other hand, identifiers in  
"Types" must always refer to type symbols (if they don't, it's a semantic  
error.)
In short, depending on the syntax tree produced in the parsing phase:
   * in a Type tree, identifiers must refer to classes, structs, aliases,  
typedefs etc.
   * in an Expression tree, identifiers can be anything.

You suggested to extend typeof to allow Types as well. I don't think  
that's a good idea and I think it's not going to happen (ie. Walter won't  
implement it.) The reason is that typeof has one perfect purpose, that is  
to get the type of an expression. I don't see any sense in passing a Type  
to typeof in order to get what you had in the beginning anyway. Maybe  
there could be a legitimate use-case for this, but I'd like to see  
convincing examples where this would be meaningful and useful.

Regards,
Aziz