Difference between "can call" and "can compile"
feepingcreature at gmail.com
Tue Sep 8 05:03:30 UTC 2020
On Monday, 7 September 2020 at 16:10:13 UTC, Steven Schveighoffer
> 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
> 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
> 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
Okay, so as far as I can see there's two avenues that should give
us both what we want. The first, and IMO best one (but W&A won't
agree) is a huge breaking language change that errors in
templates that have matched the constraints are always reported
as errors, even in a gagged context. The second, more limited one
that I think also gives you what you want (?) is a pragma *like*
__traits(compiles), maybe __traits(instantiates), with the change
that instead of gagging everything, it captures only one category
of error - "the call couldn't find a matching function or
template" - and only from the expression directly passed to it.
All other errors are reported as usual.
Would that do it?
More information about the Digitalmars-d