Difference between "can call" and "can compile"

Steven Schveighoffer schveiguy at gmail.com
Tue Sep 8 17:49:08 UTC 2020

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.

But I would be able to live with better error messages for the current 

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.

> 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.

I'm looking to duplicate the error system for functions. That is, here 
is a function signature, don't worry about the innards, if you can call 
it with that signature, then you are done with the check. Then try to 
compile what you think should be valid, and if there's an error, just 
report that error.

I don't want any of those other features. I want the equivalent of "I 
only looked at the documentation, and called the function as specified."

> 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.

> not to add unprincipled hacks to the language so that the 
> programmer can work around the compiler's deficiencies by hand.

This would be the opposite of working around things by hand. I already 
do that today.


More information about the Digitalmars-d mailing list