Whether `[const]` RPIT is `const` depends on generic parameters

[theemathas]

I'm not sure if this is correct behavior, but I find it to be rather weird, and I can't find any mention of this behavior in the RFC.

#![feature(const_trait_impl)]

const trait Trait {}

struct YesConst;
impl const Trait for YesConst {}
struct NotConst;
impl Trait for NotConst {}

fn require_const_trait(_: impl const Trait) {}

const fn not_generic() -> impl [const] Trait {
    YesConst
}

const fn generic<T: [const] Trait>() -> impl [const] Trait {
    YesConst
}

fn works() {
    require_const_trait(not_generic());
}

fn also_works() {
    require_const_trait(generic::<YesConst>());
}

fn fails() {
    require_const_trait(generic::<NotConst>());
}

error[E0277]: the trait bound `NotConst: const Trait` is not satisfied
  --> src/main.rs:29:25
   |
29 |     require_const_trait(generic::<NotConst>());
   |     ------------------- ^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     required by a bound introduced by this call
   |
note: required by a bound in `require_const_trait`
  --> src/main.rs:10:32
   |
10 | fn require_const_trait(_: impl const Trait) {}
   |                                ^^^^^^^^^^^ required by this bound in `require_const_trait`

For more information about this error, try `rustc --explain E0277`.

@rustbot labels +F-const_trait_impl

Meta

Reproducible on the playground with version 1.91.0-nightly (2025-08-09 ca77504943887037504c)

[compiler-errors]

An impl [const] Trait RPIT is only const if the "const conditions" of the RPIT are satisfied. Namely, that is the [const] predicates of the parent function that defines it. In this example, for the RPIT to implement [const] Trait, that requires T: [const] Trait to hold.

[theemathas]

So... these two are equivalent?

const fn foo() -> impl [const] Trait {}
const fn foo() -> impl const Trait {}

[compiler-errors]

Yes, but

const fn foo<T: [const] Trait>() -> impl [const] Trait {}

const fn foo<T: [const] Trait>() -> impl const Trait {}

of course are not.

[compiler-errors]

I don't think this is really actionable, so I'll opt to close it.