RFC: Fixing std.typecons.Typedef

Meta via Digitalmars-d digitalmars-d at puremagic.com
Fri Sep 2 12:40:52 PDT 2016


I was thinking about how to fix Typedef the other day and came up 
with a way of generating a guaranteed unique ID for each 
instantiation, even if they are on the same line:

alias FixedTypedef(T, T init = T.init, string cookie = new class 
{}.stringof) = Typedef(T, init, cookie);

alias Test1 = FixedTypedef!int, Test2 = FixedTypedef!int;

assert(!is(Test1 == Test2)); //Passes

What I'd like to know is if there might be a better way of doing 
this. For each instantiation of FixedTypedef, there's a new class 
being created and stored in the executable (I think), as well as 
their .stringof. This could cause a lot of bloat if Typedef is 
being used heavily.

Furthermore, would this be considered a code breakage? Looking at 
http://dlang.org/phobos/std_typecons.html#.Typedef, it says:

"Typedef allows the creation of a unique type which is based on 
an existing type. Unlike the alias feature, Typedef ensures the 
two types are not considered as equals."

This implies that the current behaviour of Typedef is a bug, and 
thus fixing it would not be code breakage. However, people may 
have come to depend on this bug and fixing it would break code. 
Thirdly, there is no point in having Typedef behave as it 
currently does by default, which is similar to how aliases 
behave. Example:

alias NewDouble = Typedef!double;
assert(!is(NewDouble == double)); //Okay, not the same type as 
expected

alias NewInt1 = Typedef!int;
alias NewInt2 = Typedef!int;
assert(is(NewInt1 == NewInt2)); //Passes?!

Thoughts? Opinions? I think it'd be nice to have a typedef that 
works correctly by default.


More information about the Digitalmars-d mailing list