Andrei Alexandrescu <seewebsiteforem...@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