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

Should we keep un-deriving traits in library to make them const? #102371

Closed
scottmcm opened this issue Sep 27, 2022 · 3 comments · Fixed by #102049
Closed

Should we keep un-deriving traits in library to make them const? #102371

scottmcm opened this issue Sep 27, 2022 · 3 comments · Fixed by #102049
Labels
T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@scottmcm
Copy link
Member

PRs like https://github.com/rust-lang/rust/pull/101698/files#diff-0752889661748b8a15a597d7156127b6fb90fdeda0627be50e07f3f785bd0f4dR678 stop using derives for traits because the derives can't make things const.

Should we maybe stop doing this in library until there's a way to #[const_derive(Ord)] or similar? It looks like we're on track to stop deriving essentially anything, which seems like a bad worldstate.

@scottmcm scottmcm added T-libs Relevant to the library team, which will review and decide on the PR/issue. I-libs-nominated Nominated for discussion during a libs team meeting. labels Sep 27, 2022
@Mark-Simulacrum
Copy link
Member

Can we get input from @rust-lang/wg-const-eval (not sure this is the right group) on the general trajectory for const impls? It was my recollection that we wanted to potentially back out the const-ification of std's traits until we had a more solid plan on that feature -- ~const and the lack of derives here is adding a lot of noise and it's not clear to me that we're not going to need to change all of these sites anyway once the feature is more complete and e.g. syntax changes.

@onestacked
Copy link
Contributor

@fee1-dead has a PR for #[derive_const] #102049

@m-ou-se
Copy link
Member

m-ou-se commented Sep 28, 2022

Should we maybe stop doing this in library until there's a way to #[const_derive(Ord)] or similar?

We discussed this in the libs meeting, and agreed that yes, we should not start changing from derives to hand-written impls everywhere just for const. #102049 looks like a good way forward for now.

@scottmcm scottmcm removed the I-libs-nominated Nominated for discussion during a libs team meeting. label Sep 28, 2022
Manishearth added a commit to Manishearth/rust that referenced this issue Nov 11, 2022
…oli-obk

Add the `#[derive_const]` attribute

Closes rust-lang#102371. This is a minimal patchset for the attribute to work. There are no restrictions on what traits this attribute applies to.

r? ``@oli-obk``
Manishearth added a commit to Manishearth/rust that referenced this issue Nov 11, 2022
…oli-obk

Add the `#[derive_const]` attribute

Closes rust-lang#102371. This is a minimal patchset for the attribute to work. There are no restrictions on what traits this attribute applies to.

r? ```@oli-obk```
Manishearth added a commit to Manishearth/rust that referenced this issue Nov 11, 2022
…oli-obk

Add the `#[derive_const]` attribute

Closes rust-lang#102371. This is a minimal patchset for the attribute to work. There are no restrictions on what traits this attribute applies to.

r? ````@oli-obk````
@bors bors closed this as completed in 4b0b898 Nov 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants