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

Bill Baxter wbaxter at gmail.com
Mon Nov 2 09:53:51 PST 2009


On Mon, Nov 2, 2009 at 8:47 AM, Don <nospam at 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



More information about the Digitalmars-d mailing list