-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow specifying an error message in &requires
#1856
Comments
Quick thought: I'd be reluctant to special-case |
This now allows to create custom error messages when `&require` condition fails. Example: type Foo = unit { x: uint8 &requires=($$ == 1 !? error"Deep trouble!'"); }; Internally, `&requires` now actually always wants an or-error expression. That remains transparent, though, because the resolver knows how to coerce a pure boolean expression into an or-error expression, crafting an error message that happens to look like what we used to produce in the past. Closes #1856
This now allows creating custom error messages when a `&require` condition fails. Example: type Foo = unit { x: uint8 &requires=($$ == 1 : error"Deep trouble!'"); # or, shorter: y: uint8 &requires=($$ == 1 : "Deep trouble!'"); }; Internally, `&requires` now always wants an or-error expression. That remains transparent to the user, though, because the resolver knows how to coerce a pure boolean `&requires` expression into an or-error expression, crafting an error message that happens to look like what we used to produce in the past. Closes #1856.
This now allows creating custom error messages when a `&require` condition fails. Example: type Foo = unit { x: uint8 &requires=($$ == 1 : error"Deep trouble!'"); # or, shorter: y: uint8 &requires=($$ == 1 : "Deep trouble!'"); }; Internally, `&requires` now always wants a condition-test expression. That remains transparent to the user, however, because the resolver knows how to coerce a pure boolean `&requires` expression into a condition test, crafting an error message that happens to look like what we used to produce in the past. Closes #1856.
This now allows creating custom error messages when a `&require` condition fails. Example: type Foo = unit { x: uint8 &requires=($$ == 1 : error"Deep trouble!'"); # or, shorter: y: uint8 &requires=($$ == 1 : "Deep trouble!'"); }; Internally, `&requires` now always wants a condition-test expression. That remains transparent to the user, however, because the resolver knows how to coerce a pure boolean `&requires` expression into a condition test, crafting an error message that happens to look like what we used to produce in the past. Closes #1856.
This now allows creating custom error messages when a `&require` condition fails. Example: type Foo = unit { x: uint8 &requires=($$ == 1 : error"Deep trouble!'"); # or, shorter: y: uint8 &requires=($$ == 1 : "Deep trouble!'"); }; Internally, `&requires` now always wants a condition-test expression. That remains transparent to the user, however, because the resolver knows how to coerce a pure boolean `&requires` expression into a condition test, crafting an error message that happens to look like what we used to produce in the past. Closes #1856.
* origin/topic/robin/gh-1856-error-expr: Fix issue with type inference for `result` constructor. Disallow dereferencing a `result<void>` value. Teach `&requires` to accept condition-tests expressions. Teach `assert` to accept an `result<void>` value. Add new "condition-test" operator.
To surface more useful errors we allow specifying an error message for
assert
statements, e.g.,We could consider adding support for similar syntax for
&requires
, e.g.,To tweak messages for
&requires
one currently needs to use a field hook. Moving this to&requires
seems natural and we already support multiple&requires
attributes.The current syntax is
&requires=COND
and above idea would be to add support for&requires=(COND [: EXPR_MSG])
. We already can parse parentheses aroundCOND
so they might not be strictly needed.The text was updated successfully, but these errors were encountered: