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

Add where clause on an impl #4508

Closed
nventuro opened this issue Mar 7, 2024 · 3 comments · Fixed by #5320
Closed

Add where clause on an impl #4508

nventuro opened this issue Mar 7, 2024 · 3 comments · Fixed by #5320
Assignees
Labels
enhancement New feature or request

Comments

@nventuro
Copy link
Contributor

nventuro commented Mar 7, 2024

Problem

I want to write an impl on some generic type T which I use in some functions that require that T implements some trait. This requires restricting each impl function with where 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 restrict T 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

@nventuro nventuro added the enhancement New feature or request label Mar 7, 2024
@nventuro
Copy link
Contributor Author

nventuro commented Mar 7, 2024

Apparently Rust also allows the above to be written as impl<T: Trait> ....

@nventuro
Copy link
Contributor Author

The error you get if you don't add the where clause in all the correct places can also be a bit confusing. It reads (assuming the code samples above):

No matching impl found for `T: Trait`

I found this weird - how could there be a matching impl if T is generic?

@jfecher
Copy link
Contributor

jfecher commented Mar 22, 2024

@nventuro there can still be a matching impl for a generic T if there is a generic impl in scope implemented for any type:

impl<T> Trait for T {
    ...
}

github-merge-queue bot pushed a commit that referenced this issue Jun 24, 2024
# 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 <jake@aztecprotocol.com>
nventuro added a commit to AztecProtocol/aztec-packages that referenced this issue Jul 11, 2024
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 <janbenes1234@gmail.com>
AztecBot pushed a commit to AztecProtocol/aztec-nr that referenced this issue Jul 12, 2024
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 <janbenes1234@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants