Open
Description
NOTE: See #110395, which tracks a planned rewrite of this feature's implementation
This is the primary tracking issue for rust-lang/rfcs#2632.
The current RFC text can be found at https://internals.rust-lang.org/t/pre-rfc-revamped-const-trait-impl-aka-rfc-2632/15192
This RFC has not yet been accepted. It is being implemented on a provisional basis to evaluate the potential fallout.
cc #57563
The feature gate is const_trait_impl
.
Components
#[const_trait]
attributeimpl const Trait
T: ~const Trait
append_const_msg
onrustc_on_unimplemented
#[derive_const]
trait Destruct
Open issues
- const trait checks allow calling non-const methods #88155
- this test shows we can currently still call a
const fn
with aTrait
bound even if the concrete type does not implementconst Trait
, but justTrait
. This will fail later during evaluation. Some related discussion can be found in Allow using generic trait methods inconst fn
#79287 (comment) - There are no tests for using a
const impl
without defining one without the feature gate enabled. This should be added before anyimpl const
is added to the standard library. - We need some tests and probably code around
#[rustc_const_stable]
and#[rustc_const_unstable]
so we can properly stabilize (or not) the constness of impls in the standard library -
impl const
wrongly accepts impl with non-const provided methods #79450 shows that with default function bodies in the trait declaration, we can cause non-const functions to exist inimpl const Trait
impls by leaving out these default functions - We need to determine the final syntax for
~const
. (In the interim, we may want to switch this to use ak#provisional_keyword
or similar.) - If we need
#[default_method_body_is_const]
, determine the syntax for it instead of existing as an attribute -
#[derive_const]
for custom derives (proc macros) Provide a way for derives to know if they were invoked with#[derive_const]
#118304
When stabilizing: compiler changes are required:
- Error against putting
rustc_const_unstable
attribute onconst
impl
s as they are now insta-stable. - Treat
default_method_body_is_const
bodies andconst
impl
bodies asstable
const fn
bodies. We need to prevent accidentally stabilizing an implementation that uses unstable lang/libconst fn
features. - Change Rustdoc to display
~const
bounds or what syntax we decided it to be.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Assignees
Labels
Area: Constant evaluation (MIR interpretation)Area: const fn foo(..) {..}. Pure functions which can be applied at compile time.Area: Trait systemCategory: A tracking issue for an RFC or an unstable feature.`#![feature(const_trait_impl)]`Status: The feature will stay unstable indefinitely.Relevant to the language team, which will review and decide on the PR/issue.