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.

On Friday, 2 September 2016 at 19:40:52 UTC, Meta wrote:
> 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.

Why did my auto-generated gravatar picture change?

On Friday, 2 September 2016 at 19:40:52 UTC, Meta wrote:
> 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:
>
> [...]
>
> 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.

IMHO, a better solution would be a __UNIQUE_UUID__ special token, which the compiler replaces with a randomly generated (or guaranteed unique, if we cannot afford a strong enough random algorithm) UUID (or identifier, or whatever you prefer).

But if we cannot have it, a library function that does what you propose may be useful, as unique strings may also be helpful in other places.

> 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?!

I see the current behaviour not as a bug, but as a not-well-documented feature. In fact, the current behaviour allows you to create families of types which are considered equal. This method is different from `alias`, as it is based on strings and thus it does not require visibility of the aliased type.

What we surely want is an easy way to guarantee that a Typedef is in fact unique. This can be done with another template `UniqueTypedef`, or having an easy way to generate unique strings (see my idea above):

alias t = Typedef!(int, int.init, __UNIQUE_UUID__);

On Sat, 03 Sep 2016 11:34:02 +0000, Lodovico Giaretta wrote:
> I see the current behaviour not as a bug, but as a not-well-documented feature.

It's the default behavior, though, and it does nearly the opposite of what you probably want.