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

Seal traits inside impl_ submodule #3908

Open
davidhewitt opened this issue Feb 27, 2024 · 12 comments
Open

Seal traits inside impl_ submodule #3908

davidhewitt opened this issue Feb 27, 2024 · 12 comments

Comments

@davidhewitt
Copy link
Member

Off the back of #3897 (comment)

Should we review the traits inside the impl_ submodule, check which ones can be sealed, and do that? It's a reasonable safety mechanism to prevent users from trying to implement those things.

@davidhewitt
Copy link
Member Author

I labelled this "Good First Issue", as this is an internal refactoring which would be great to have.

A "sealed" trait has a private supertrait, thus making it possible to implement outside the crate. All of the PyAnyMethods and similar traits are sealed, for example. Take a look at src/sealed.rs as the trait we use as the supertrait for most sealing.

@Cheukting
Copy link
Contributor

@davidhewitt I am happy to have a look at this

@davidhewitt
Copy link
Member Author

Brilliant, thanks 🙏

@Cheukting
Copy link
Contributor

Cheukting commented Jun 15, 2024

@davidhewitt quick question, are there any particular reasons something should be or should not be moved? Or is it ideally everything should be moved from impl_ to Sealed? I want to make sure I fully understand this.

@davidhewitt
Copy link
Member Author

I don't think we should be moving any code, this issue is about upgrading trait Foo to trait Foo: Sealed where it makes sense to do so for the traits inside the impl_ submodule.

@Cheukting
Copy link
Contributor

I see, so those traits that could be used by the user need to be Sealed right? Thanks for clarifying it @davidhewitt

@davidhewitt
Copy link
Member Author

Yes, in principle many things inside impl_ are accessible by users but we never intend them to use them directly (just via the macros). The worry is there might be traits in there which we would prefer users can't implement at all, hence the sealing.

@Cheukting
Copy link
Contributor

Thank you for your patience, I was occupied by EuroPython preparation in the last few weeks. I plan to pick this one up again this weekend or next week.

@davidhewitt
Copy link
Member Author

I think the next step along here would be finding traits which make use of the private_impl! helper and changing them all to be Sealed instead (and remove the old helper).

@Cheukting
Copy link
Contributor

@davidhewitt @LilyFoote is this issue closed? It seems so to me

@davidhewitt
Copy link
Member Author

I think there are still lots of traits in impl_ (search for pub trait) which do not have a Sealed bound. So it looks like there is more which can be done.

@Cheukting
Copy link
Contributor

Cool, I will go treasure hunt when I got the time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants