Tracking issue for closed RFC 2632, `impl const Trait for Ty` and `[const]` (conditionally const) syntax (`const_trait_impl`)

[ecstatic-morse]

NOTE: See #110395, for context about why this feature's implementation got rewritten from scratch, requiring the temporary removal of const traits from libcore

This issue will be closed in the future in favor of rust-lang/rfcs#3762

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] attribute
• impl const Trait
• T: ~const Trait
• append_const_msg on rustc_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 a Trait bound even if the concrete type does not implement const Trait, but just Trait. This will fail later during evaluation. Some related discussion can be found in Allow using generic trait methods in const 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 any impl 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 in impl 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 a k#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
• grep for 110395 and figure out what to do everywhere that issue is mentioned (this is old stuff left over from when the previous const trait impl was removed)
• add a perf stress test for const trait impls and complex bounds that need solving

When stabilizing: compiler changes are required:

• Error against putting rustc_const_unstable attribute on const impls as they are now insta-stable.
• Treat default_method_body_is_const bodies and const impl bodies as stable const fn bodies. We need to prevent accidentally stabilizing an implementation that uses unstable lang/lib const fn features.
• Change Rustdoc to display ~const bounds or what syntax we decided it to be.

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. Discussion comments will get marked as off-topic or deleted. Repeated discussions on the tracking issue may lead to the tracking issue getting locked.