Ideas how to improve template constraint errors???

[monarch_dodra]

On Thursday, 5 December 2013 at 13:55:30 UTC, Martin Nowak wrote:
> Ah well, this was a question for ideas.
> I don't really know to get there.

IMO, one of the initial problems is "argument type validation" vs 
"overload resolution".

I've talked about this some before: 
http://forum.dlang.org/thread/znlqobvvdywdskhiriwx@forum.dlang.org

It's the kind of thing that I think makes some of our constraints 
too complicated.

--------

This would not have helped you in this situation. While a backend 
solution would be nice, I also think the library can itself keep 
things in check by limiting gratuitous overloads, when an 
internal static if will be enough.

Also, judicious use of traits can help clarify the situation. In 
some extreme situations, I think writing an explicit trait that 
"consolidates" a couple of traits at once helps: Keeping the 
length of the constraint in check always helps.

For example, having a "std.algorithm.areComparableRanges!(R1, 
R2)" would help a *ton* of algorithms, while keeping things a bit 
clearer. Keeping them as "package" means we can write them 
without having to worry too much about public use.

--------

Finally, one of the things I had toyed with, but never got to 
submitting, were "assertive traits".

I had written something you could add in code, such as:

//----
struct R {...}

checkIsRandomAccessRange!R;

void main()
{}
//----

With this, if R was *not* an actual random access range, it 
failed with an assert that said something along the lines of:
R is not a BidirectionalRange because it does not have back.
R is not a RandomAccessRange because it is not a 
BidirectionalRange.

While it was quite the useful "trait", it required about 4 times 
the code to implement as the trait itself, and required parallel 
maintenance :/