Difference between "can call" and "can compile"
snarwin at gmail.com
Tue Sep 8 18:24:47 UTC 2020
On Tuesday, 8 September 2020 at 17:49:08 UTC, Steven
> 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
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.
More information about the Digitalmars-d