Library Typedefs are fundamentally broken

[Wyatt via Digitalmars-d]

On Wednesday, 17 September 2014 at 02:57:03 UTC, Freddy wrote:
> When you have separate 2 typedefs of the exact same type, they
> are equal.While this maybe able to be solved with
> Typedef!(Typedef!(...)) different modules typedef ing the same
> type (most likely build-in types) would have their typedef be
> equivalent thereby degrading the purpose of typedef.
> ---
> import std.typecons;
>
> alias meter = Typedef!float;
> alias feet = Typedef!float;
> static assert(!is(meter==feet));
> ---
> Your thoughts?

Reading this thread and thinking on it more... I acknowledge this 
is probably kind of naive, but it makes aliases feel 
not-very-useful to me.

It doesn't give you type checking or function overloading because 
as far as the semantic pass is concerned, they're identical.  And 
that's fine.  The documentation on AliasDeclaration is kind of 
verbose, but it does clarify that at some point (had to reread it 
a couple times to notice, though...).  So I get that aliasing is 
at least situationally useful (e.g. utility shortening), and I 
think it's been stated repeatedly that it's great for 
metaprogramming things, but the aggregate makes this situation 
suck.

If you want those things to work, you have to wrap it in a struct 
and use alias this (which IS a legitimately cool application of 
the aliasing semantics, I'll grant).  This can be mitigated 
somewhat, but it still feels inelegant and not-D-like for 
something I'd really like to use easily and often.  Also, for the 
hardcore among you, I think your cache may hate you for this (I 
don't recall if that overhead gets optimised away).

I think you could be forgiven for expecting std.typecons.Typedef 
to provide the alternative we need, but it ends up being only 
about as useful as typedef in C (or maybe a bit less?).  Is there 
some better solution I've missed?  (I wouldn't consider the 
cookie parameter a better solution; I would consider it a wart.)

-Wyatt