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

FeepingCreature feepingcreature at gmail.com
Fri Jan 17 05:54:39 UTC 2020


On Thursday, 16 January 2020 at 17:30:57 UTC, H. S. Teoh wrote:
> 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.

I think he means they're semantic errors rather than parser 
(syntax) errors.

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

Would be nice, but would be a hard spec change. This is the sort 
of thing that D should have been doing from the beginning, but we 
may be too far in now for __traits(compiles) to be changed to do 
this. However, this is the behavior I would ask for for 
__traits(canInstantiateWith).



More information about the Digitalmars-d mailing list