Library Typedefs are fundamentally broken

[Andrei Alexandrescu via Digitalmars-d]

On 9/22/14, 9:21 AM, Wyatt wrote:
> 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.

I would agree with that. If I'd do it over again I'd probably make the 
string the second argument with no default.

> You can make the argument that it's not that much of a burden. And on a
> cursory read, sure, that makes enough sense.

It's a good argument. At some point some RTFM is necessary; I think it's 
reasonable to assume that whoever is in the market for using Typedef 
would spend a minute with the documentation.

> 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.

Type safety is not the problem here. I do agree that surprising behavior 
for those who don't RTFM is possible.

> 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.

I'd agree with that. (Again if I could do things over again there'd be 
no default for the cookie.) But my understanding is that there's quite a 
bit of blowing this out of proportion.

> 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).

It's an anecdote. How you explained matters matters a lot :o). I find 
the requirement for the cookie perfect.


Andrei