http://dlang.org/deprecate.html#typedef
"typedef is not flexible enough to cover all use cases. This is
better done with a library solution."
[Citation needed]
What use cases is it not flexible enough for?
This is tangentially related to my other topic about template
visibility, specifically the alias I'm trying to do to my
binderoo.math.vector.VectorFloat.
The problem with alias is that it won't instantiate an entirely
new symbol. It's effectively a hard link to another symbol.
Trying to resolve the module name won't actually give me what I
want here.
Maybe the deprecated typedef will get me what I want? I can't
make Visual D respect my -d command line properly, so I can't get
in and quickly check if things are okay there.
Right, so off to the library solution, std.typecons.Typedef. Uh.
This isn't a typedef. This embeds one type within another and
tries to mimic that type as much as possible. And it makes that
member private. You know what this means - if I try to parse over
it for my serialisation pass for Binderoo, I can't use __traits(
allMembers ) to get to it. Also, technically, since it's an
object within an object it will need to double up on the JSON
hierarchy to store it unless I get in and specialise it.
At the very least, it seems here that Typedef should actually be
called TypeWrapper, it would actually make sense for its
functionality there.
Which gets back to the keyword typedef. Sure, it's not as
flexible as alias. And I don't even know if a typedef in one
module would result in a symbol resolution to that module or not.
But what was the actual problems with it?
