On 9/23/14, 8:10 AM, Wyatt wrote:
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.
I'm not buying this. Yah, there's batteries of types a la Windows'
definitions, but it's not like casual use everywhere.
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?)
Sure, the lesser the better. But it's a continuum, not beside the point.
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).
Then define and use defineTypedef. Clearly there's an imbalance between
the desire of getting work done with Typedef and that of ildly arguing
that Typedef is useless.
People who need to get work done won't be stopped by Typedef. They'll
type it twice and if they need it a third time then they'll figure how
to simplify its usage. Or they use Adam's idiom (Adam makes this point
in his epic slideless talk: just get into it and make it work! I've
never seem Adam working himself to a foam over minutia.)
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.
That's a loose use of the term.
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.
Not buying all this, sorry.
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!
The guy who started this thread was explained what to do, replied with
"Sorry, my mistake" and went on his way getting stuff done.
And the solution in this case is conceptually simple.
What would that be?
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.
I'd be fine with improving Typedef. In fact part of the rationale for
replacing the built-in with a library type is that we have more
flexibility in library space.
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! ;)
That's great.
Andrei
