Proposal: static template(fail)

[Jason House]

Janice Caron Wrote:

> On 12/14/07, Jason House <jason.james.house at gmail.com> wrote:
> > I've always been under the impression that use of static if is the "D way".
> 
> It's a choice. It happens to be my /preferred/ choice, but the
> multiple-templates way still needs to be supported.

After reflecting, I agree.  What I'd been talking about assumes a mostly orthogonal split of template parameters rather than a hierarchy of approximate matches.  Here's something more along the lines of what I was thinking about:

template(T,U)       { void foo(); }
template(T : int,U){ void foo(); }
template(T,U : int){ void foo(); }
foo!(int,int)();

If both the 2nd and 3rd template works, which should the compiler choose?

Maybe The 2nd template should assert U can't be int and the 3rd template should assert T can't be int.  Even if that's done, is it an error or should the default be used?  It very well could be the programmer never intended both parameters to be integers.  Using the generic default may be a logic error.  In this type of situation, I think it may help to force the programmer to be more explicit... such that if they don't catch this case properly, instantiating with both ints should be a compile-time error.



> Even if you /only/ use the static if style, and there are no
> alternative overloads, at the end of your chain of static ifs, you
> still want to be able so say static template(fail) (or whatever syntax
> is deemed right), rather than static assert, because if the template
> can't be instantiated at all, yes there's an error /somewhere/ -- but
> it's not in the template code; it's in the calling code - and that's
> the only place an error should be reported.

I have to disagree here.  That's like saying it's incorrect to use an assert in an "in" contract.  The same logic could apply.  The caller passed in incorrect data, so the error occurred in the caller, not the callee.  I just can't buy that.  The callee can provide context-specific errors (free text detailing the likely problem or the logical condition that failed).

I don't view template instantiation any differently.  If there's an error, I want to templated code's perspective of what the error is *and* a complete backtrace.  Now, when I say "an error", I mean a real error...  It may be true that SFINAE when alternatives exist, but when you exhaust alternatives, it's an error.