Uniform syntax for templates (second try)

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Oct 12 09:15:59 PDT 2008


Marcin Kuszczak wrote:
> Well, I am not saying that this is top-priority change right now. I am just
> saying that it would be better to have it implemented - it should be a way
> to go. I really don't have an idea how much work is it to implement this.
> The fact is that most pieces are already in-place, they just have to be
> connected together. Maybe it would be possible to introduce this change
> partially, finally depreciating is() completely? There will be probably not
> so much impact on user code, as only heavily templated code (using matching
> by e.g. static arrays) will be affected. Common cases will stay exactly the
> same.

Why are you sure deprecating is() is a goal in and of itself? You 
mention beginners are having trouble understanding it, but then you'd 
need to make a pretty good case that beginners won't have much trouble 
understanding your way. (It took me a while.)

Besides one good thing about is() is that it allows you to match type 
patterns without error. For example:

static if (is(T = V[K], K, V)) {
     // T is a hash, use K and V
} else static if (is(T = V[], V)) {
     // T is an array, use V
} ...

In contrast, aliasing can only fail with a compile-time error:

alias T K V : T = V[K];

I agree that using a symbol before clarifying that it's being introduced 
is odd. Anyhow, it would be great if more people added to this exchange 
to get a feel of the level of interest.


Andrei



More information about the Digitalmars-d mailing list