Proposal: prettify template constraints failure messages

[monarch_dodra]

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 >:(