Difference between "can call" and "can compile"

[Paul Backus]

On Tuesday, 8 September 2020 at 13:57:34 UTC, Steven 
Schveighoffer wrote:
>
> What we would need is a new feature that then we can migrate 
> existing code to use.

On the other hand, improving the compiler to give more 
informative output about existing errors in existing code 
requires no migration and solves this entire category of problem, 
rather than just the subset involving IFTI or template argument 
deduction.

>> 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?
>
> Yes, this is exactly what I'm looking for. I was going to call 
> it __traits(canCall) or something, but instantiates makes 
> perfect sense, since this only really is important for template 
> instantiation.

If we're going to take this approach, why stop here? Surely there 
are other categories of error that a programmer might want to 
query: __traits(parses), __traits(resolvesIdentifiers), 
__traits(typeChecks), __traits(safetyChecks), 
__traits(passesCtorFlowAnalysis), etc. Might as well go ahead and 
add them all.

The problem described in the OP of this thread is that the 
compiler fails to give the programmer useful information in 
certain situations. The solution is to improve the compiler so 
that it gives better information, not to add unprincipled hacks 
to the language so that the programmer can work around the 
compiler's deficiencies by hand.