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