Tracking Issue for removing `impl const` and `~const` in the standard library

[fee1-dead]

This is a tracking issue for removing impl const and ~const in the standard library. This is carried out so that migrating to a new implementation under keyword generics can go more smoothly. See this Zulip thread for discussion around this operation.

For temporary preview of the effects rewrite, add feature(effects) to your crate code. Most bugs/misbehaviors are known so consider opening a thread on the project-const-traits stream on Zulip before opening an issue.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Remove unstable features that currently use const traits: Rm const traits in libcore #110393
• Remove logic in the compiler around const traits to allow a better implementation
  • Remove constness from ParamEnv #114134
  • Remove constness from TraitPredicate #114202
  • Remove constness from ImplSource::Param #114781
• Land a better implementation in the compiler (see previous attempt at reimplement ~const Trait bounds via a fourth kind of generic param #101900).
  • Effects/keyword generics MVP #113210
  • Effects: don't print host param in diagnostics #114203
  • correctly lower impl const to bind to host effect param #114545
  • Implement fallback for effect param #115727
  • treat host effect params as erased in codegen #115817
  • Canonicalize effect vars in new solver #115850
  • Fallback effects even if types also fallback #115859
  • Ensure that ~const trait bounds on associated functions are in const traits or impls #116210
  • Hide host effect params from docs #116670
  • Duplicate ~const bounds with a non-const one in effects desugaring #116756
  • Don't compare host param by name #116870
  • Use elaboration to turn ~const bounds into non-const bounds #116872
  • Deny providing explicit effect params #117171
  • Deny more ~const trait bounds #117817
  • Add Span to TraitBoundModifier #118245
  • Remove a hack for effects #118246
  • effects: Run enforce_context_effects for all method calls #118282
  • Fix Deref args when #[const_trait] is enabled #118386
  • Remove #[rustc_host], use internal desugaring #118605
  • Use default params until effects in desugaring #118608
  • Implement new effects desugaring #120639
• Restore unstable features using const traits
  • Disable effects in libcore again #116856
  • Reenable effects in libcore #117825
  • Reconstify Add #120381
  • Remove use of const traits (and feature(effects)) from stdlib #126552

Tasks

Preview Give feedback

No tasks being tracked yet.

[Thomasdezeeuw]

It would have been nice to update the old tracking issue: #92391 so that people that actually try these feature are notified when things (are going to) change, instead of just breaking their code one day...

[AaronKutch]

Hello, I did not see this coming. I fully understood that, as an unstable feature, const traits would likely have their syntax updated, or feature gates changed, or some special cases like around Destruct changed, etc. However, I did not expect an almost fundamental looking thing like this to be removed entirely. My crate awint depends on a few things but especially const Deref/DerefMut/AsRef/AsMut/From in order to support ergonomic const bigint operations and proper storage/DST reference separation. An early version of my crate from back before const Trait used a function for this, but literally half of the code was just getting at references. It is going to require thousands of lines of changes within the crate and outside in order to go back to something much worse. How soon is impl const going to be reimplemented, and could it be expedited like how they want const_convert back? Should I open an issue or is it expected that re~const-ifying most of the standard library will come quickly after the reimplementation?

[fee1-dead]

Re ~const-ifying will eventually happen, and once we have a polished enough implementation these features will be restored.

[hecatia-elegua]

Hi, why can't this be removed after the better implementation lands in the compiler?
Of course I can instead pin my nightly version to before the removal, but depending on the time it takes until keyword generics work, I might be "stuck" there.
I totally get it if that's just not a possiblity since it would bloat the compiler or keep two different impls of the same thing alive or whatever, though.

Edit: I just put this stuff behind a feature gate, since it mostly only affects code optimization.

[fee1-dead]

@hecatia-elegua: The removal is supposed to make it so that it is easier to land the better implementation. Therefore, the procedure is removal -> better implementation -> restoration. Removing after the better implementation makes no sense, since we'd still want to continue to experiment const traits until stabilization of a better syntax.