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 (bearophileh...@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