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

Don nospam at nospam.com
Mon Nov 2 11:19:40 PST 2009


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.

>> 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.



More information about the Digitalmars-d mailing list