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

Beta 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.

[slightlyoutofphase]

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.

I may be misunderstanding your wording / intent here, but the removal (which makes it impossible to do certain things that were previously possible with const traits, by any means) seems to be in direct opposition to "continued experimentation".

More specifically, I have a crate that for example would in theory need to add both const_intoiterator_identity and const_default_impls amongst other things to get updated for nightly-2023-04-14-and-earlier compatibility from its current state.

However, while the former flag does still exist, the latter doesn't. Why this is the case, like why only some things were removed down to the actual feature gate, is not clear at all and seems very arbitrary. That's what's mostly confusing people with regards to this, I think, the fact that you didn't actually remove everything, just some things.

[fee1-dead]

Continued experimentation happens after we improve the implementation in the compiler. There is absolutely no guarantee for unstable features that they will continue to exist tomorrow, since the point of unstable is for us to make breaking changes until it is good enough to be stabilized.

As to why the removal isn't happening alongside the pr that would change the internal compilation, we wanted to make it so that the refactor would be easy to review, therefore including the const traits removal changes in the same pr would be increasing its complexity.

As for partial removal, I don't know either. All const impls should be removed. If not then there might be a mistake.

[AaronKutch]

I find it hard to believe that the current implementation is so tangled that it would require tearing out everything up to the API level rather than progressively refactoring the different underlying aspects while keeping the public functionality working continuously. Since there are people freely contributing we can let things slide for a few months, but if the functionality is not restored in, say, by the end of the year I'd call this approach completely botched. A month in, I'm not seeing any progress at all from a cursory search. I sure hope someone has been working on something locally.

[Noratrieb]

Const traits are an unstable feature and as such no guarantees are provided. The people actively working on it know what's best for the future of the feature and have the most experience with it. Most Rust contributors are volunteers, and therefore it's hard to give concrete timelines or plans. If you want to accelerate development of a feature, consider helping instead. If you're interested, join the Zulip.

[Frostie314159]

The original message should probably be updated, because the second task appears to have been completed(i.e. all PRs merged).

[Houtamelo]

What is the status on this RFC? It seems there are only 2 issues left and they are very close to completion.

#118386
Seems to just be waiting for a review.

#116872
Author claims that the issue was superseeded by #119721, which has already been merged.

[fee1-dead]

It is still being worked on, with the most recent work happening at #120639.

[AaronKutch]

What's the current status right now?

[fee1-dead]

What's the current status right now?

You're invited to follow development updates on the project goals issue: rust-lang/rust-project-goals#106 :) I'll lock this issue for now because tracking issues are mostly for logging procedural concerns and linking developments, and not for discussion. Feel free to ask on our Zulip channel in the future.