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

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

Closed
2 of 4 tasks
fee1-dead opened this issue Apr 16, 2023 · 16 comments
Closed
2 of 4 tasks
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-effects `#![feature(effects)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@fee1-dead
Copy link
Member

fee1-dead commented Apr 16, 2023

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

Tasks

Preview Give feedback
No tasks being tracked yet.
@fee1-dead fee1-dead added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Apr 16, 2023
equation314 added a commit to arceos-org/arceos that referenced this issue Apr 20, 2023
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
equation314 added a commit to arceos-org/arceos that referenced this issue Apr 20, 2023
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
@Thomasdezeeuw
Copy link
Contributor

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

reflyable pushed a commit to reflyable/arceos-udp that referenced this issue Apr 22, 2023
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
@AaronKutch
Copy link
Contributor

AaronKutch commented Apr 27, 2023

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
Copy link
Member Author

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

@hecatia-elegua
Copy link
Contributor

hecatia-elegua commented Apr 27, 2023

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
Copy link
Member Author

@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
Copy link
Contributor

slightlyoutofphase commented May 20, 2023

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
Copy link
Member Author

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
Copy link
Contributor

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
Copy link
Member

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.

bors added a commit to rust-lang-ci/rust that referenced this issue Oct 26, 2023
…ct-params, r=oli-obk

Deny providing explicit effect params

r? `@oli-obk`

cc rust-lang#110395
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Oct 28, 2023
…, r=oli-obk

Deny providing explicit effect params

r? `@oli-obk`

cc rust-lang/rust#110395
@fmease fmease added F-effects `#![feature(effects)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 2, 2023
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 18, 2023
…nkov

Reenable effects in libcore

With rust-lang#116670, rust-lang#117531, and rust-lang#117171, I think we would be comfortable with re-enabling the effects feature for more testing in libcore.

r? `@oli-obk`
cc `@fmease`
cc rust-lang#110395
@Houtamelo
Copy link
Contributor

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
Copy link
Member Author

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

Celve added a commit to Celve/recore that referenced this issue Mar 12, 2024
According to rust-lang/rust#110395, const
traits cannot be used anymore.
Celve added a commit to Celve/recore that referenced this issue Mar 12, 2024
According to rust-lang/rust#110395, const traits cannot be used anymore.
Azure-stars pushed a commit to Starry-OS/page_table_entry that referenced this issue May 1, 2024
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
Azure-stars pushed a commit to Starry-OS/spinlock that referenced this issue May 1, 2024
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
Azure-stars pushed a commit to Starry-OS/memory_addr that referenced this issue May 1, 2024
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
Azure-stars pushed a commit to Starry-OS/driver_block that referenced this issue May 1, 2024
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
Azure-stars pushed a commit to Starry-OS/axerrno that referenced this issue May 1, 2024
Otherwise it will fail to compile on nightly-2023-04-19

See rust-lang/rust#110395
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 30, 2024
Make `has_attr` check behind effects feature

attempt to fix the performance regression in rust-lang#120639.

cc rust-lang#110395

r? project-const-traits
@AaronKutch
Copy link
Contributor

What's the current status right now?

@fee1-dead
Copy link
Member Author

fee1-dead commented Aug 25, 2024

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.

@rust-lang rust-lang locked as off-topic and limited conversation to collaborators Aug 25, 2024
@RalfJung
Copy link
Member

I'm confused about what is being tracked here. The issue title talks about tracking the removal of these impls, which AFAIK is completed. So either the issue should be closed or the issue title updated, I think.

@jhpratt
Copy link
Member

jhpratt commented Oct 30, 2024

I'm inclined to agree. There is #67792 for the feature itself, so this issue shouldn't be used for that purpose. Everything appears to be completed, so I'll close this issue. If I'm mistaken, feel free to reopen it of course.

@jhpratt jhpratt closed this as completed Oct 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC F-effects `#![feature(effects)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests