Deprecated tracking issue for closed RFC 2632, impl const Trait for Ty and ~const (tilde const) syntax (const_trait_impl)

[ecstatic-morse]

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] 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.

[RalfJung]

I think the new RFC should get a new tracking issue (once it gets accepted). There's too much no-longer-relevant history in this one.

[loynoir]

What about HRTB?

Fail to compile when HRTB + const trait

pub mod reproduce {
    #[const_trait]
    pub trait ConstFrom<T>: Sized {
        #[must_use]
        fn const_from(value: T) -> Self;
    }

    #[const_trait]
    pub trait ConstAddAssign<Rhs = Self> {
        fn const_add_assign(&mut self, rhs: Rhs);
    }

    pub fn incr42<T>(mut x: T)
    where
        T: const ConstFrom<u8> + for<'a> ConstAddAssign<&'a T>,
    {
        let delta = T::const_from(42u8);

        x.const_add_assign(&delta)
    }

    pub const fn const_incr42<T>(mut x: T)
    where
        T: const ConstFrom<u8> + for<'a> const ConstAddAssign<&'a T>,
    {
        let delta = T::const_from(42u8);

        x.const_add_assign(&delta)
    }
}

[quratoop]

The Bound must be T: ~const not T: const

[loynoir]

@quratoop

The Bound must be T: ~const not T: const

Still not able to compile.

    pub const fn const_incr42<T>(mut x: T)
    where
        T: ~const ConstFrom<u8> + for<'a> ~const ConstAddAssign<&'a T>,
    {
        let delta = T::const_from(42u8);

        x.const_add_assign(&delta)
    }

[quratoop]

Hmm, I can't find a quick solution. I spent some time looking into the const_trait_impl feature, but never really in combination with HRTBs. I imagine it's not currently supported, which is trivial since you can declare the traits.

[fmease]

@quratoop You need to also add the bound ~const std::marker::Destruct to T (additionally requires feature const_destruct).

---

This is a tracking issue, for the record. If you have a bug with a specific feature, please open a new issue! If you want to discuss the implementation, please also open a new issue and it can be tagged C-discussion. Tracking issues have a linear history so they are not conducive to any kind of discussion.

---

CC'ing the new RFC, RFC 3762, again, for which we would open a new tracking issue on approval as Ralf wrote.
Also CC other channels of communication: #t-compiler/project-const-traits (implementation) and #t-lang/effects (overall design).