Library Typedefs are fundamentally broken

[ketmar via Digitalmars-d]

On Sat, 20 Sep 2014 10:20:28 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

> >> I think this is an entirely palatable idiom:
> >> alias ALfloat = std.typecons.Typedef!(float, "ALfloat");
> > this is ugly.
> But not unusable.
tying code using my nose is entirely possible too, and it even fun. but
it's far from being "usable technique".

> Are you saying you're giving up on an entire design because you can't 
> bring yourself to type one string?
not just one string. people will use ugly features only when they are
forced to. D makes using typedefs unnecessarily ugly, thus
marginalising them. turn struct declaration to "Declare!struct" and
leave class declaration as-is, and people will start use classes
instead of structs, even when struct is better fit. or remove "string"
alias.

what i'm trying to say is that "typedef" is "core feature" if we are
talking about type safety, and it should be nice or people will not use
it. current "Typedef" is not nice.

> > the whole thing with aliasing Typedef is broken.
> s/broken/less convenient than a builtin/ and we agree.
no, it is broken. for such important feature "less convient" means
"broken".

> uuugly != broken
"==" for this case.

> Not sure I understand this last point. At any rate, if your entire
> line of reasoning hinges on you being unwilling to type a few more
> characters to have a workable solution, I have difficulty taking it
> seriously.
i don't want "workable solution", i want "usable solution". "Typedef"
is barely usable due to being one of fundamental features and uuugly.
make something ugly and people will avoid it as much as they can. if we
don't care about compile-time type safety... ok, let it stay ugly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140920/49c2c1c5/attachment-0001.sig>