Producing nicer template errors in D libraries

[Steven Schveighoffer]

On Wed, 11 Apr 2012 10:33:26 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 4/11/12 9:23 AM, Steven Schveighoffer wrote:
>> Essentially, you are still forcing this sequence:
>>
>> int func(T)(T arg) if(constraint) {...}
>> int func(T)(T arg) if(!constraint) {...}
>>
>> when the second line could just be:
>>
>> int func(T)(T arg) else {...}
>>
>> I don't see the benefit of enforcing the else branch to give an error.
>
> I advocated this to Walter and he talked me out of it.
>
> Essentially template constraints help choosing the right overload given  
> the arguments. Just like overloading, such selection should proceed  
> across modules. If we have an "else" template we give up on that  
> approach.

How so?  The if/else if/else is used to find a template to match within  
that module.  It doesn't affect other modules.  Right now, all the if  
statements from all modules are combined.  This wouldn't change that.  For  
example, you have:

if(module1.constraint1)
    matches++;

if(module2.constraint1)
    matches++;
if(module2.constraint2 && !module2.constraint1)
    matches++;

This then becomes:

if(module1.constraint1)
    matches++;

if(module2.constraint1)
    matches++;
else if(module2.constraint2)
    matches++;

In other words, else is shorthand for "and doesn't match any other  
previous constraints in this module".  It looks pretty DRY to me...

I don't see how this affects ambiguity between modules at all.

>  Besides, it's extremely rare that a template works with an open-bounded  
> set of types.

Maybe, but you can rely on the template not compiling in those cases.

-Steve