-
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
Minimally constify Add
#133237
base: master
Are you sure you want to change the base?
Minimally constify Add
#133237
Conversation
Agreed regarding const stability attributes. We currently do require them for regular
I also feel like we should not repeat what we did last time and have a big "const trait everything" spree until we are confident that the system works and we can stabilize the first parts. We need to do experimentation to gain that confidence, of course, but IMO last time we went too far in using this unstable feature throughout the standard library before it was ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this test also call twice
from const context?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me after test tweak
@bors r=compiler-errors |
…iler-errors Minimally constify `Add` * This PR removes the requirement for `impl const` to have a const stability attribute. cc `@RalfJung` I believe you mentioned that it would make much more sense to require `const_trait`s to have const stability instead. I agree with that sentiment but I don't think that is _required_ for a small scale experimentation like this PR. rust-lang/project-const-traits#16 should definitely be prioritized in the future, but removing the impl check should be good for now as all callers need `const_trait_impl` enabled for any const impl to work. * This PR is intentionally minimal as constifying other traits can become more complicated (`PartialEq`, for example, would run into requiring implementing it for `str` as that is used in matches, which runs into the implementation for slice equality which uses specialization) Per the reasons above, anyone who is interested in making traits `const` in the standard library are **strongly encouraged** to reach out to us on the [Zulip channel](https://rust-lang.zulipchat.com/#narrow/channel/419616-t-compiler.2Fproject-const-traits) before proceeding with the work. cc `@rust-lang/project-const-traits` I believe there is prior approval from libs that we can experiment, so r? project-const-traits
impl const
to have a const stability attribute. cc @RalfJung I believe you mentioned that it would make much more sense to requireconst_trait
s to have const stability instead. I agree with that sentiment but I don't think that is required for a small scale experimentation like this PR. Add const stability tracking for traits project-const-traits#16 should definitely be prioritized in the future, but removing the impl check should be good for now as all callers needconst_trait_impl
enabled for any const impl to work.PartialEq
, for example, would run into requiring implementing it forstr
as that is used in matches, which runs into the implementation for slice equality which uses specialization)Per the reasons above, anyone who is interested in making traits
const
in the standard library are strongly encouraged to reach out to us on the Zulip channel before proceeding with the work.cc @rust-lang/project-const-traits
I believe there is prior approval from libs that we can experiment, so
r? project-const-traits