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

[rmcguire]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
 
> 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
> 

I really like 'static' as the namespace, it would be awesome if it did not just 
contain 'meta' stuff.

Could we lose 'pragma', 'typeof', unary 'is', 'typeid', '__traits'.

It makes a lot of sense to just say to someone "if you want to do something at  
compile time, just check the 'static' documentation".

-Rory