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.
-Steve
More information about the Digitalmars-d
mailing list