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