typedef keyword?

[F.Almeida]

Extensions to turn typedef into a more useful construct have already
been proposed, but discussion on this has not evolved much since.

My first, naive, idea was shown here:
http://www.digitalmars.com/webnews/newsgroups.php?
art_group=digitalmars.D&article_id=114489

Both the syntax and the rules to enforce casting would need some
work, but the basic idea is give the programmer control over which
types such a variable can cast to and from.

== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> In D.learn I have just given an answer about alias/typedef, in it
I have said that the decision to deprecate typedef was in the end
the right one:
> http://www.digitalmars.com/webnews/newsgroups.php?
art_group=digitalmars.D.learn&article_id=22387
> But once some time is passed, what do you want to do with the
typedef keyword? Just remove it and turn its usage in a syntax
error? Keep in mind that the original purpose of typedefs in D was
not imaginary, it was present to help a real need. If you program a
little in Pascal/ObjectPascal/Ada you quickly learn that a typedef
is useful.
> So in my opinion a better solution is to design a better typedef,
that uses the "typedef" keyword, and supports a more flexible
semantics, as Andrei has suggested. This new usage of the "typedef"
keyword may even be introduced in D3, there's no need to rush. The
usage of "alias this" in structs will help, but a new usage of the
typedef keyword may be syntax sugar for something else defined in
Phobos. This new syntax of typedef may require a () after the
keyword, to give space to specify the alternative kinds of typedef:
> typedef(subtype) ... ...
> The syntax typedef(...) is (I think) not syntactically compatible
with C, so there is no problem with introducing a similar syntax
with different semantics (this is even an improvement over D1, where
typedef acts unlike C language).
> Bye,
> bearophile