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/[email protected]
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 :/
