Producing nicer template errors in D libraries

[Steven Schveighoffer]

On Wed, 11 Apr 2012 07:42:54 -0400, Don Clugston <dac at nospam.com> wrote:

>
> This is the way we used to do it, before we had template constraints.
> Although it works OK in simple cases, it doesn't scale -- you need to  
> know all possible template constraints.
>
> I would like to see something in the language conceptually like:
>
> int func(T)(T arg) else { ... }

I'd go further.  I'd like to see else if as well.

Currently, you have to repeat conditions from previous template  
constraints:

int func(T)(T arg) if (constraint1) {...}
int func(T)(T arg) if (!constraint1 && constraint2)

It's like writing a large if sequence without the benefit of else.   
Sometimes you even need to put && !constraint2 in the first version.

> for a template which is instantiated only if all constraints have  
> failed. 'default' is another keyword which could be used, and  
> 'if(false)' is another, but else is probably more natural.
> Any attempt to instantiate an 'else' template always results in an  
> error, just as now. (in practice: if instantiating the else template  
> didn't trigger a static assert, a generic error message is issued)

Why go this far?  Why can't you have an else that's instantiated?

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.

-Steve