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