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

[scottmcm]

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.

[Mark-Simulacrum]

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]

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

[m-ou-se]

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.