So why was typedef bad?

Ethan Watson via Digitalmars-d digitalmars-d at puremagic.com
Wed Aug 31 06:44:51 PDT 2016


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?


More information about the Digitalmars-d mailing list