On Wed, 11 Apr 2012 10:33:26 -0400, Andrei Alexandrescu
<[email protected]> 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
