Difference between "can call" and "can compile"

[FeepingCreature]

On Monday, 7 September 2020 at 16:10:13 UTC, Steven Schveighoffer 
wrote:
>
> This is somewhat different than what I was proposing. However, 
> it's very closely related.
>
> I absolutely need it to be matched with a function call, I 
> don't want to have to do type acrobatics or check for UFCS, or 
> whatever.
>
> However, I think both our needs are satisfied if the feature is 
> something like checking to see that all symbols are resolved 
> and that all instantiations are unambiguous. What happens after 
> that should be considered a normal ungagged error.
>
> If I can pull out a non-template analogy, imagine you had code 
> like:
>
> int foo()
> {
>    blahblah(); // unresolved symbol
> }
>
> int bar()
> {
>    return foo();
> }
>
> And instead of the error on the "blahblah" line, you got an 
> error that foo doesn't exist, and so bar cannot be compiled. 
> This is kind of how the current template state of affairs is. I 
> want the same benefits for template code that non-template code 
> has.
>
> -Steve


Yesss.

Okay, so as far as I can see there's two avenues that should give 
us both what we want. The first, and IMO best one (but W&A won't 
agree) is a huge breaking language change that errors in 
templates that have matched the constraints are always reported 
as errors, even in a gagged context. The second, more limited one 
that I think also gives you what you want (?) is a pragma *like* 
__traits(compiles), maybe __traits(instantiates), with the change 
that instead of gagging everything, it captures only one category 
of error - "the call couldn't find a matching function or 
template" - and only from the expression directly passed to it. 
All other errors are reported as usual.

Would that do it?