Proposal: Replace __traits and is(typeof(XXX)) with a 'magic namespace'.

[Andrei Alexandrescu]

Don wrote:
> Andrei Alexandrescu wrote:
>> Don wrote:
>>> [I'm moving this from deep inside a TDPL thread, since I think it's 
>>> important]
>>>
>>> is(typeof(XXX)) is infamously ugly and unintuitive
>>> __traits(compiles, XXX) is more comprehensible, but just as ugly.
>>>
>>> They are giving metaprogramming in D a bad name. I think we need to 
>>> get rid of both of them.
>>>
>>> A very easy way of doing this is to replace them with a 'magic 
>>> namespace' -- so that they _look_ as though they're functions in a 
>>> normal module.
>>> Names which have been suggested include 'meta', 'traits', 'scope', 
>>> 'compiler'. Personally I think 'meta' is the nicest (and I suggested 
>>> two of the others <g>).
>>
>> Another keyword, sigh...
>>
>> And I'll be darned if "static" isn't the perfect fit :o).
> 
> I suggested 'scope', as well, if you need to minimize keywords.
> You can get rid of typeid, though, which is a real keyword, by moving it 
> to the same namespace.

Well ok. Anyhow, something we need to integrate: one problem with typeid 
is that it should return the dynamic type for class objects. For 
example, typeid(this) in an abstract class or an interface should return 
the TypeInfo for the derived class. I was majorly surprised that that's 
not the case at all. Walter acknowledged that he's given a few tries at 
providing decent run-time reflection hooks (typeid, classinfo) but none 
really work. He agreed that the entire mechanism is due for a thorough 
review.

>>> This would give us:
>>>
>>> meta.compiles(XXX)
>>> meta.isArithmetic; // note, property syntax OK if no arguments
>>> meta.isArithmetic(int*);
>>
>> isArithmetic is library-implementable. How would the library inject 
>> stuff in the meta namespace? 
> 
> It could be done from inside traits.c in the compiler. If the function 
> isn't on the list of instrinsics, it can be converted into a function 
> call in the same name.
> 
> Also my alarm goes off when seeing
>> meta.isArithmetic(int*) instead of meta.isArithmetic!(int*), which is 
>> what the unwashed masses would have to do if they wanted to implement 
>> a similar facility. With time I've acquired a dim view of certain 
>> stuff in the language benefiting of untouchable advantages.
> 
> Agree, and that's what I see a severe problem with __traits -- nothing 
> in the language looks ANYTHING like it.
> This is just what you get if you apply the patch as-is, giving you 
> exactly what you get from __traits. There has to be a few special cases 
> -- there's no way of doing .compiles() with existing language features 
> (maybe in the future with macros?) But, by introducing a magic 
> namespace, it's possible to introduce some forward compatibility.
> 
> There are two fundamental points I'm making with this proposal:
> (1) we ought to have higher expectations for this part of the language; and
> (2) considerable improvement can be made with very little effort.
> 
> The proposal itself is almost immaterial. It's the result of hacking the 
> compiler for twenty minutes. If we can do even better, that'd be fantastic.

I'm (almost) all for it. If it didn't add a keyword, I'd have been 110% 
for it. Anyhow, the only important part is what Walter thinks.


Andrei