-
Notifications
You must be signed in to change notification settings - Fork 230
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
Add where clause on an impl #4508
Comments
Apparently Rust also allows the above to be written as |
The error you get if you don't add the
I found this weird - how could there be a matching impl if |
@nventuro there can still be a matching impl for a generic impl<T> Trait for T {
...
} |
# Description ## Problem\* Resolves #4508 ## Summary\* This enables the simple functionality of being able to declare a where clause directly on a struct implementation such as below: ```rust impl<T> MyStruct<T> where T: MyEq { fn my_eq(self, other: Self) -> bool { (self.a == other.a) & self.b.my_eq(other.b) } } ``` The code above is essentially syntactic sugar where we now every method in the struct impl a where clause. As the logic for resolving trait constraints already exists this PR really just updates the parser to accept `where` clauses and during definition collection attaches them to each method in an impl. ## Additional Context ## Documentation\* Check one: - [ ] No documentation needed. - [X] Documentation included in this PR. - [ ] **[For Experimental Features]** Documentation to be submitted in a separate PR. # PR Checklist\* - [X] I have tested the changes locally. - [X] I have formatted the changes with [Prettier](https://prettier.io/) and/or `cargo fmt` on default settings. --------- Co-authored-by: jfecher <[email protected]>
Now that we can have a `where` that [affects an entire `impl`](noir-lang/noir#4508), I thought I'd give this a try in the state variables. Often I've felt tricked by these implementations, since when trying to work with them the requirements for a given generic `T` seem fairly low, but then they add up as I start calling more and more functions, which each add their own trait bounds. The interface ends up feeling dishonest and not really showing all you need to do (all the traits that must be implemented) in order to be able to use the thing. With this change, the entire impl now requests up front all trait bounds, though it does mean we're a bit more restrictive than strictly needed. I don't think this is an issue - yes, you don't need to be able to serialize in order to read a public mutable, but you can only read if you write before, and that requires serialization. So all in all it seems like we always end up indirectly requiring all traits. --------- Co-authored-by: benesjan <[email protected]>
Now that we can have a `where` that [affects an entire `impl`](noir-lang/noir#4508), I thought I'd give this a try in the state variables. Often I've felt tricked by these implementations, since when trying to work with them the requirements for a given generic `T` seem fairly low, but then they add up as I start calling more and more functions, which each add their own trait bounds. The interface ends up feeling dishonest and not really showing all you need to do (all the traits that must be implemented) in order to be able to use the thing. With this change, the entire impl now requests up front all trait bounds, though it does mean we're a bit more restrictive than strictly needed. I don't think this is an issue - yes, you don't need to be able to serialize in order to read a public mutable, but you can only read if you write before, and that requires serialization. So all in all it seems like we always end up indirectly requiring all traits. --------- Co-authored-by: benesjan <[email protected]>
Problem
I want to write an impl on some generic type
T
which I use in some functions that require thatT
implements some trait. This requires restricting each impl function withwhere T: Trait
, which leads to a lot of repetition.Happy Case
Ideally I'd simply do
impl<T> MyStruct<T> where T: Trait { ... }
instead of having to restrictT
in each function. This is of course less granular, but I imagine in most scenarios this coarse restriction would be fine.This happens in many places in aztec-nr, where most if not all functions need the clause.
Ultimately this is just syntax sugar though.
Project Impact
Nice-to-have
The text was updated successfully, but these errors were encountered: