C++ guys hate static_if?

[Peter Alexander]

On Saturday, 9 March 2013 at 16:22:43 UTC, monarch_dodra wrote:
> ...which brings us to managing said overloads. Basically, right 
> now, if you want overloads, you have to repeat the conditions 
> in a:
>
> if (a && !b)
> ...
> if (b && !c)
> ...
> if (c)
>
> This is minor, but it does not scale very well, especially if 
> "a", "b" and "c" are complicated. In algorithm, some of our 
> constraints for sort/find can be 5 lines long. At this point, 
> can we still say that they are readable tools for users, or an 
> implementation tool for dispatch?

I agree this is a problem. sort didn't have constraints for a 
long time. I added them not long ago, but if I'm being perfectly 
honest, I'm not 100% convinced I've done it correctly. It's 
incredibly difficult to examine a non-trivial function to see 
what the correct constraints are.

btw, you have a bug :-)  If the arguments match constraints a and 
c, but not b then the call will be ambiguous on the first and 
third.

Another problem with constraints is that if you want to add a 
specialisation, you can't do it without changing the existing 
functions, e.g.

void foo(R)(R r) if (isInputRange!R)

If I want to add a better version for random access ranges, I 
cannot just add:

void foo(R)(R r) if (isRandomAccessRange!R)

I also have to modify the original:

void foo(R)(R r) if (isInputRange!R && !isRandomAccessRange!R)

I suppose a better solution to this problem would involve someway 
of specifying that random access ranges are a subtype of input 
ranges, and the overload resolution would recognise that the 
random access range version is preferable to the more general 
version when available. I can't see a way to do this in general 
with constraints.