Difference between "can call" and "can compile"

Steven Schveighoffer schveiguy at gmail.com
Mon Sep 7 16:10:13 UTC 2020

On 9/7/20 11:48 AM, FeepingCreature wrote:
> But say that I forgot to import std.datetime. Then __traits(compiles) 
> will return false and I will have no idea what happened. What I actually 
> *want* is __traits(canInstantiate, decode, SysTime) - check if the 
> template constraints can be satisfied enough to find an unambiguous 
> template match. If I then try to instantiate the template and the 
> compiler raises an error, that's okay! That's an error I want. I want 
> that error. Give me that error. Please. :)
> (Note that this doesn't *exactly* reduce to a function call. An 
> important part here is that I don't know what the function will be 
> called with; I have to instantiate the function template so that I can 
> check what parameters it requires, which I'll then recursively try to 
> decode.)

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.


More information about the Digitalmars-d mailing list