Propagating Errors

Johannes Pfau nospam at example.com
Thu Mar 7 22:14:16 UTC 2019


Am Wed, 06 Mar 2019 12:48:08 +0000 schrieb FeepingCreature:

> Personally, I think the problem comes down to this: we have no way of
> propagating errors from  inside template constraints to the user.
> 
> I think the way to go is instead of returning `false`, have
> __traits(compiles) (which is really the core source of these
> difficulties) return an "error object" that evaluates to false, but also
> encodes additional information about the problem, recursively.
> 
> Propagate this through short-circuiting - ErrorObject && bla = true, bla
> && ErrorObject = ErrorObject, etc.
> 
> The compiler can then pick up on the fact that an error object was the
> reason why a template constraint failed to give a highly informative
> error message.

I see we both had the same idea! Instead of special casing 
traits(compiles) and making the compiler deduce an error message I'd let 
the CTFE library code do that, see my post about 
__traits(constraintCheck). Also we should allow reporting multiple errors 
at once, instead of one at a time (e.g. a Type not implementing front and 
popFront for input ranges should report both problems at once).

But something like this is in my opinion the best way to go.


-- 
Johannes


More information about the Digitalmars-d mailing list