Skip to content
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

Open
bbannier opened this issue Sep 6, 2024 · 1 comment
Open

Allow specifying an error message in &requires #1856

bbannier opened this issue Sep 6, 2024 · 1 comment
Assignees
Labels
Feature Request Request for new functionality

Comments

@bbannier
Copy link
Member

bbannier commented Sep 6, 2024

To surface more useful errors we allow specifying an error message for assert statements, e.g.,

assert False : "the things broke!!!1";

We could consider adding support for similar syntax for &requires, e.g.,

type X = unit {
    : uint8 &requires=($$ == 0 : "%d is not a good value" % $$);
};

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 around COND so they might not be strictly needed.

@rsmmr
Copy link
Member

rsmmr commented Sep 6, 2024

Quick thought: I'd be reluctant to special-case &requires with a syntax that's not simply an expression (because expressions is what all other attributes expect, and this still looks like an expression). But we might be able to make this work with plain expressions actually if we change &requires to expect an expression of type result<bool>. And then add some short-cut constructor syntax that yields either true or an error, like $$==0 ?|| error"%d is not a good value" % $$). (Not saying that is the syntax we want, just a possible example; and interpolation doesn't work for errors yet, but would be easy to add.). This would also be backwards-compatible because a plain boolean coerces into result<bool>.

@rsmmr rsmmr self-assigned this Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request Request for new functionality
Projects
None yet
Development

No branches or pull requests

2 participants