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
