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

Closed
bbannier opened this issue Sep 6, 2024 · 1 comment · Fixed by #1929
Closed

Allow specifying an error message in &requires #1856

bbannier opened this issue Sep 6, 2024 · 1 comment · Fixed by #1929
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
rsmmr added a commit that referenced this issue Nov 26, 2024
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
rsmmr added a commit that referenced this issue Nov 27, 2024
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.
rsmmr added a commit that referenced this issue Nov 28, 2024
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.
rsmmr added a commit that referenced this issue Nov 28, 2024
@bbannier bbannier linked a pull request Nov 28, 2024 that will close this issue
rsmmr added a commit that referenced this issue Nov 28, 2024
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.
rsmmr added a commit that referenced this issue Nov 28, 2024
rsmmr added a commit that referenced this issue Dec 3, 2024
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.
rsmmr added a commit that referenced this issue Dec 3, 2024
rsmmr added a commit that referenced this issue Dec 4, 2024
@rsmmr rsmmr closed this as completed in 4b4d165 Dec 4, 2024
rsmmr added a commit that referenced this issue Dec 4, 2024
* 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.
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

Successfully merging a pull request may close this issue.

2 participants