Compile-time reflection

[Lutger]

Kirk McDonald wrote:
...
>> This looks very confusing to me, however, if you'd replace the first 
>> static with 'is' it makes sense:
>>
>> is(A.bar == static) == false
>> is(A.bar == final) == false
>> is(A.bar == virtual) == true
>>
>> Is there a problem with this, grammar-wise?
>>
>> Btw, if introducing 'virtual' is undesirable, it can be left out since 
>> it can be inferred from being final nor static, and for this some 
>> library side syntactic sugar can be made.
>>
> 
> Grammar wise, using 'virtual' would cause some problems. (What if you 
> have a type called 'virtual' and want to compare some other type to it?) 
> There is another, more serious, problem: is() is defined such that if 
> the first thing passed to it isn't a type, it returns false. (That is, 
> one of its purposes is to test if something is a valid type.) I think 
> that making an exception to this rule for 'static' and 'final' could 
> potentially be confusing. Therefore, some other keyword is required. I 
> picked 'static' more or less arbitrarily. It also allows the use of 
> 'virtual' directly.
> 

I see. Well, it's not that important, the big thing is if the 
functionality will be included. Still I would argue that it is 
preferable to use 'is', because it's both clearer and more consistent.

The problem with is() returning false when the symbol tested isn't a 
type occurs now too, I don't understand how this is different from 
current cases with static / final / virtual?

If we need to hose virtual, one would have to write:
!(is(A.bar == static) || is(A.bar == final))

This is less than ideal, but I can live with that for the benefit it 
gives. In practice I would wrap it anyway in some traits module.