You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think we should add support for #[rustc_const_(un)stable] attributes on traits. That would set a feature gate which would be required to
use this trait in a ~const Trait or const Trait bound
write a const impl for that trait
call any function from this trait in const context
(All of these also require the const_trait_impl feature gate on top of the per-trait feature gate.)
Currently we have a #[const_trait] attribute; every trait in a staged-api crate that has that attribute should then also be required to have a const stability attribute.
For now, making such a trait rustc_const_stable should be forbidden since the feature is not ready yet. Or maybe we rely on the extra gating with the const_trait_impl feature for that? Once a trait is rustc_const_stable, all its const impl must also be marked rustc_const_stable.
The text was updated successfully, but these errors were encountered:
…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
I think we should add support for
#[rustc_const_(un)stable]
attributes on traits. That would set a feature gate which would be required to~const Trait
orconst Trait
boundconst impl
for that trait(All of these also require the
const_trait_impl
feature gate on top of the per-trait feature gate.)Currently we have a
#[const_trait]
attribute; every trait in a staged-api crate that has that attribute should then also be required to have a const stability attribute.For now, making such a trait
rustc_const_stable
should be forbidden since the feature is not ready yet. Or maybe we rely on the extra gating with theconst_trait_impl
feature for that? Once a trait isrustc_const_stable
, all itsconst impl
must also be markedrustc_const_stable
.The text was updated successfully, but these errors were encountered: