On Mon, Nov 2, 2009 at 8:47 AM, Don <nos...@nospam.com> 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>). This would give us: > > meta.compiles(XXX) > meta.isArithmetic; // note, property syntax OK if no arguments > meta.isArithmetic(int*); > > Benefits: > * Fewer keywords: __traits -> meta, typeid() -> meta.typeid() > * Get rid of is() expressions, which are the most complicated thing in the > language. > * Some meta.XXX functions could be defined in runtime library code. > * The existing __traits functions could have more useful return values. > * Retain the flexibility of __traits.
I don't understand what you are proposing to replace "is()" with. I also don't understand what it means to call meta.isArithmetic with no argument. But I agree that meta.blah() looks more like part of an intentional design than __traits(blah, ...). Even meta(blah, ...) would be a significant improvement. I already see people trying to heap on other refactorings and redesigns on top of this proposal. While certainly more could be done, I think it's worth while to go ahead with just making the syntax not look hideous. If you try to roll this in with a more global reform, it's just going to get bogged down like 95% of the other conversations that start up here and go anywhere. Let's take it one step at a time. Do the renaming first, then we can work on the next step after the first step is taken. --bb