Feature request: __traits(canInstantiate), like __traits(compiles) but without suppressing syntax errors

[H. S. Teoh]

On Thu, Jan 16, 2020 at 11:00:03AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 1/15/20 10:13 AM, FeepingCreature wrote:
> > Right now it's impossible to check "is there a valid (template)
> > specialization for this function call" without also saying "and by
> > the way, if there's a syntax error in the function, suppress the
> > error and return false."
> 
> I know what you mean, but they are not syntax errors (which ARE
> errors, even in templates). Which makes them really difficult to
> categorize.

Yeah, they are gagged errors that are nevertheless relevant to the
problem at hand.  But it's very hard, from the compiler's standpoint, to
know which gagged errors are relevant and which are not (most are not,
in speculative template instantiations).

I'm tempted to propose that anything that passes sig constraints
*should* force the compiler to treat any errors in the function body as
hard (non-gagged) errors.  But then you also have sig constraints that
fail due to gagged errors, and it's not clear at all which of those
should be treated as hard errors.


[...]
> Generally, I use hasMember instead of __triats(compiles) and I'm
> better off for it. If something defines a member by a specific name,
> then it better be what I'm looking for, so try using it. If not, then
> you'll just have to name it something else. I'm not sure Phobos can
> take this road though.
[...]

Yeah, over time I've learned to avoid __traits(compiles) as much as
possible. It's just far too general, and unhelpful when problems occur.
(Why doesn't it compile? It could be any number of reasons, most of
which probably the person who wrote the __traits(compiles) didn't even
think of.)

But anyway, recent versions of dmd are now more helpful, by pointing out
which sig constraints are failing, rather than just a blanket "cannot
match template" error.  The next step IMO is to somehow display a brief
summary of why that (or those) particular constraint(s) are failing.
It's already quite helpful to know, e.g., that a template function
failed to match because isInputRange!R failed. But isInputRange contains
quite a number of further constraints; it would be nice to at least have
an option to show the dirty details of where that particular constraint
failed.

I've no idea how to implement such a thing, though.


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have
biases.  He/She has prejudices. -- Gene Wirchenko