Difference between "can call" and "can compile"

[Paul Backus]

On Tuesday, 8 September 2020 at 17:49:08 UTC, Steven 
Schveighoffer wrote:
> On 9/8/20 1:06 PM, Paul Backus wrote:
>> 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 error could cause subtle differences. The code could 
> actually COMPILE, but not take the path intended. In which case 
> the error is useless, even if it's more verbose.

I guess I've failed to communicate clearly. When I talk about 
"errors" here, unless I specifically say otherwise, I am 
referring exclusively to "top-level" non-speculative errors--the 
kind that DMD prints with red letters and that cause compilation 
to fail.

By definition, any code that contains such an error cannot 
compile, so the hypothetical you raise here is impossible.

> And by better error messages, I mean show me where my code 
> failed to compile, not give me 5 pages of speculative 
> compilation errors up a giant tree of calls.

Well, the compiler is already showing you where your code failed 
to compile: it failed in the template constraint, because 
`__traits(compiles, whatever)` evaluated to false. :)

What you and I really want is for the compiler to show us the 
*root cause* of that failure (which `-verrors=spec` currently 
succeeds at), and to do so without overwhelming us with 
irrelevant information (which `-verrors=spec` currently fails at).

>> 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
>
> If you can solve that problem, then I'd be all for that.

If it's possible to selectively un-gag errors based on whether 
they happened during template argument deduction, it should also 
be possible to selectively un-gag errors based on whether they 
happened during template instantiation in general.