Closed
Description
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.
Activity
TypeId
ordering impls #101698Mark-Simulacrum commentedon Sep 27, 2022
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 commentedon Sep 27, 2022
@fee1-dead has a PR for #[derive_const] #102049
m-ou-se commentedon Sep 28, 2022
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.
#[derive_const]
attribute #102049Rollup merge of rust-lang#102049 - fee1-dead-contrib:derive_const, r=…
Rollup merge of rust-lang#102049 - fee1-dead-contrib:derive_const, r=…
Rollup merge of rust-lang#102049 - fee1-dead-contrib:derive_const, r=…
Rollup merge of rust-lang#102049 - fee1-dead-contrib:derive_const, r=…