-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Comments
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
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... |
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
Hello, I did not see this coming. I fully understood that, as an unstable feature, |
Re |
Hi, why can't this be removed after the better implementation lands in the compiler? Edit: I just put this stuff behind a feature gate, since it mostly only affects code optimization. |
@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. |
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 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. |
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. |
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. |
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. |
…param-env, r=oli-obk Remove `constness` from `ParamEnv` This should be replaced by keyword generics/effects. cc rust-lang#110395 r? `@oli-obk`
…ct-params, r=oli-obk Deny providing explicit effect params r? `@oli-obk` cc rust-lang#110395
…, r=oli-obk Deny providing explicit effect params r? `@oli-obk` cc rust-lang/rust#110395
…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
It is still being worked on, with the most recent work happening at #120639. |
According to rust-lang/rust#110395, const traits cannot be used anymore.
According to rust-lang/rust#110395, const traits cannot be used anymore.
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
Otherwise it will fail to compile on nightly-2023-04-19 See rust-lang/rust#110395
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
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. |
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. |
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. |
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
constness
fromParamEnv
#114134constness
fromTraitPredicate
#114202ImplSource::Param
#114781~const Trait
bounds via a fourth kind of generic param #101900).host
param in diagnostics #114203impl const
to bind to host effect param #114545~const
trait bounds on associated functions are in const traits or impls #116210~const
bounds with a non-const one in effects desugaring #116756~const
trait bounds #117817Span
toTraitBoundModifier
#118245enforce_context_effects
for all method calls #118282Deref
args when#[const_trait]
is enabled #118386#[rustc_host]
, use internal desugaring #118605Add
#120381feature(effects)
) from stdlib #126552Tasks
The text was updated successfully, but these errors were encountered: