On Saturday, 20 September 2014 at 04:52:58 UTC, Andrei
Alexandrescu wrote:
alias A = Typedef!float;
alias B = Typedef!float;
By basic language rules, A and B are identical. Making them
magically distinct would be surprising...
Hold up. See, "Making them magically distinct would be
surprising" is really the sticking point for me because in my
experience it rings false.
When I reach for a typedef, I expect these things to NOT be
identical. More to the point, I'm explicitly stating: "This
thing is not like any other thing." That's the fundamental
reason any sort of typedef exists in my world. That the
idiomatic library Typedef doesn't actually give these semantics
unless I do extra stuff? _That_ is surprising and inconvenient.
I'm personally having difficulty coming up with a situation where
the current default behaviour is even useful.
You can make the argument that it's not that much of a burden.
And on a cursory read, sure, that makes enough sense. But it's
still there and still acts as positive punishment. We tend to
tout type safety as a major feature, which builds the expectation
that getting it for the common case is _completely trivial_ and
in-line with the pragmatic approach taken by the rest of the
language. Adding a gotcha like this makes it less likely to be
used correctly.
And I think it needs to be stressed: No one is arguing that the
current behaviour shouldn't be possible at all; just that it's an
unusual special case that makes for a warty default. If you want
two distinctly-named types to hash the same, give them a common
cookie and be on your merry way. Meanwhile, the issues with e.g.
Typedef in templates disappear because it makes introducing a
unique type the trivial default.
Anecdotally, I was explaining how neat it is that D has library
Typedef to an engineer on my team and he commented that he'd
never expect a word like "alias" to be associated with defining a
distinct type, suggesting its use here is a misfeature. He also
called the cookie parameter a wart (unprompted).
-Wyatt
