Library Typedefs are fundamentally broken

[Wyatt via Digitalmars-d]

On Monday, 22 September 2014 at 17:21:50 UTC, Andrei Alexandrescu 
wrote:
>
> I would agree with that. If I'd do it over again I'd probably 
> make the string the second argument with no default.
>
That's not the problem though.

>> 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.
>
Even just reading this thread, I can see that the people in the 
market for using Typedef also want to use it _often_ (a sentiment 
I echo) because trivial type safety is such a compelling feature. 
  The fact that it's documented is beside the point. (I thought 
you or Walter talked before about how "RTFM" isn't a shining 
endorsement of your API?)  The fact that its primary use isn't 
the default presents a usability problem.  For one thing, no one 
likes writing boilerplate.  It's annoying.  When things are 
annoying, people find some other way.  But there's another aspect 
that makes this even worse (below).

> Type safety is not the problem here. I do agree that surprising 
> behavior for those who don't RTFM is possible.
>
I beg to differ.  Type safety is the entire goal.  Surprising 
behaviour shouldn't be the default when the "Surprise!" part is 
that it doesn't break until later.  That surprises should explode 
spectacularly at their earliest convenience is a lesson you 
taught me with e.g. the rationale behind using NaN as the 
floating point init value.  By failing to detonate, errors can 
manifest in the implementation subtly after appearing to work for 
an extended period.  This is bad.

You said earlier it's reasonable to assume people would read the 
docs, and I agree to an extent.  But I think it's reasonable to 
want APIs in the standard library that are resistant to 
misreading, skimming, and misunderstanding.  That very sort of 
confusion is why this thread even started, after all!  And the 
solution in this case is conceptually simple.

> 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

Generating a unique cookie if one isn't given is the correct 
behaviour from the _user's_ perspective.  I believe it also 
addresses the concerns Timon raised regarding Typedef in 
templates.

> that there's quite a bit of blowing this out of proportion.
>
I agree some of the discussion has been hyperbolic, but I also 
agree there's a real problem with the current situation that goes 
beyond simply "this is moderately annoying".

> It's an anecdote. How you explained matters matters a lot :o). 
> I find the requirement for the cookie perfect.
>
Something like, "Look how cool it is that we can do typedefs as a 
template!" and a link to the docs.  Just an anecdote from a non-D 
user that ended up being relevant. (I'm trying to score converts! 
;)

-Wyatt