On Wednesday, 2 January 2013 at 21:43:31 UTC, Jonathan M Davis
wrote:
On Thursday, January 03, 2013 01:25:17 Dmitry Olshansky wrote:
What do you think?
Hmmm. Typically the thing that you really want to know is which
portions were
true and which were false, and this doesn't help with that at
all. What it
does is make the errors more understandable for newbies, which
is good. But
for those of use who know more, they'd actually be annoying I
think, because
what I really want to know is what the actual constraint was so
that I can
figure out what's wrong. But I'm likely to look at the source
for that anyway,
since it's far more legible there than it is the error message.
So, this could be a good idea in that it could make the errors
more
understandable for newbies, but it still really doesn't help
tell you what's
wrong, which is what you really want to know. It just tries to
translate the
constraint into English. So, I don't know.
I'm not opposed to the idea, but I'm not exactly sold on it
either. Certainly,
I don't think that it would benefit me, personally, at all, but
it may be worth
it for newbies.
- Jonathan M Davis
Well, to be honest, some of our overloads are really
*complicated*. I swear that for some of them, even understanding
what the constraint are and why is a huge headache. Having some
english in there can't hurt, IMO. That said, judicious use of
traits (even private traits) can achieve the same goal, and
reduce the complexity.
----
That said, I think another field of improvement we should
concentrate in phobos is to have a single public entry point, and
then privately forward to private specialized overloads.
Users really shouldn't have to deal with functions whose
restraints are things such as "input range, but not random
access", or "random access with length, but not sliceable" or
some of our other *6* liners. It gets especially bad when the
compiler lists all 7 of our (implementation defined) overloads.
Nobody needs to see that.
As a end user, I'd really want to see a single function with
"isForwardRange!R". Period. The fact that the implementation
differs depending on all that *crap* really isn't my problem and
shouldn't show up in my interface >:(
