Reducing template constraint verbosity? [was Re: Slides from my ACCU Silicon Valley talk]

[Andrei Alexandrescu]

On 12/14/10 1:43 PM, Steven Schveighoffer wrote:
> On Tue, 14 Dec 2010 13:51:50 -0500, so <so at so.do> wrote:
>
>>> Any idea how this can be 'solved' or do we need to continue doing
>>> things like this? My naive instinct is to use the declaration order
>>> to determine a match (first one to match wins), but that kind of goes
>>> against other overloads in D.
>>
>> One big plus of current solution is that everything you need for that
>> specialization lies in the signature.
>> I can't see another approach that scales better at this. If scaling
>> for constraints is something important.
>>
>> In:
>> void foo(R)(R r) if(isRandomAccessRange!R) {...}
>> void foo(R)(R r) if(isInputRange!R && !isRandomAccessRange!R) {...}
>>
>> void foo(R)(R r) if(isInputRange!R && !isRandomAccessRange!R) {...}
>> We can deduce it is equal to:
>> void foo(R)(R r) if(isInputRange!R) {...}
>>
>> For single/two constraints it isn't hard, when things get ugly
>> determining what means what is not quite easy as far as i can see.
>> Just consider if your first specialization had two constraints.
>
> On the contrary, I think it scales very poorly from a function-writer
> point of view.
>
> Let's say I wanted to add a version that implements a specialization for
> forward ranges, I now have to modify the constraint on the one that does
> input ranges. This is opposite to how derived classes or specialized
> overloads work, I just define the specialization, and if it doesn't
> match it falls back to the default.
>
> Imagine now if I wanted to define a foo that worked only on my specific
> range, I now have to go back and modify the constraints of all the other
> functions. What if I don't have control over that module?

It scales poorly on artificial examples. It scales well on real-world 
examples, because those usually have disjunctive constraints.

Andrei