# const traits in practice

this document highlights what we learned about const traits by actually using them in libcore and in tests.

## important things

in no particular order

### impl trait bounds

it is fairly common to repeat trait bounds from impl blocks but with a `[const]` bound added. impl blocks in contrast to trait impls can't be const, even if all methods within it are const. this can lead to annoying repetition.

:::info
`const impl` blocks that make all methods within it const and are allowed to have `[const]` trait bounds https://github.com/rust-lang/rust/pull/148434 (implemented). All methods within `const impl` are const, without explicit `const fn`.
:::

:::info
`impl const Trait for Type` is now `const impl Trait for Type`
:::

### format traits and functions

require `dyn [const] Trait`, which needs a lot of design work to make sure we don't end up with people writing impls for both `dyn const Trait` and `dyn Trait` and potentially all other future effects.

:::info
at this stage we're just assuming we'll figure it out in the future, there doesn't seem anything fundamental here, just figuring out all the intricacies and making it all ergnonomic
:::

### Eq and other method-less traits

made them const so people could just change any `Eq` bound to a `[const] Eq` bound instead of needing to do `Eq + [const] PartialEq`

### Destruct bound hints vs precise live drops

need too many destruct bounds without precise live drops.

suggestion: stabilize together, to avoid ecosystem churn where everyone adds excessive Destruct bounds and removes them later when we stabilize precise drops

### no const closures

basically don't have them for the same reason we don't have dyn const trait. constness does not exist in types, only as trait bounds and during trait solving. we have not worked on a coherent plan for it at all, so basically at this stage we're just assuming we'll figure it out in the future. const traits is already immensly useful on its own without closure support.

### Deriving const traits

is only possible for libstd. Ecosystem derives need to invent their own scheme (e.g. a #[const] attribute in addition to the #[derive]), but it would all be convention. Do we want to either prescribe a convention by making libstd derives work a specific way or do we want to expose derives directly in the proc macro infra?

### Bug with Copy/Clone derive order

Const traits makes it more likely to hit the bug in [#124794](https://github.com/rust-lang/rust/issues/124794). To avoid this, if `Copy` and `Clone` are in different derives, `Copy` should come before `Clone` for the best generated code.

// Copy should go before Clone
#[derive(Copy)]
#[derive_const(Clone)]
struct Example;

### core traits and their relationships

#### Copy Clone

pub const trait Copy: [const] Clone

ideally Copy would imply const Clone and not require Copy to be a const trait at all. but that would obviously be a breaking change. tho less of one if we did a funny and made all non-const impls of Clone for types that are Copy actually require const for the Clone methods and treat the impl as a const impl. would still break some code, but that code must be fishy as hell

#### Copy Destruct

https://github.com/rust-lang/rust/issues/133214#issuecomment-3336327623

Copy should imply const Destruct as that's what ownership analysis treats it as, so the trait solver should , too

#### impl const Clone for Option symptom

This is a symptom of a more general issue, but where we noticed it is that `Clone::clone_from` needs a `Self: [const] Destruct` bound for the default impl which is just `*self = source.clone()`. Now when someone overwrites this impl (e.g. Option), they actually want a `T: [const] Destruct` bound, not an `Option<T>: [const] Destruct` bound. Unfortunately `Option<T>: Destruct` currently does not imply `T: Destruct`. So we need to mark the entire `const Clone for Option` impl as having a `[const] Destruct` bound.

### RPIT constness is coarse-grained.

In the below function, it's impossible to write the bounds so that the RPIT is const iff `T: const Trait1`, while the function is const iff `U: const Trait2`.

const fn foo<T: [const] Trait1, U: [const] Trait2>(x: T) -> impl [const] Trait3 {
    U::something();  // requires U: const Trait2 for foo to be a const fn
    Wrapper(x)  // requires T: const Trait1 for the RPIT to be const
}

### #[const_trait] attribute is rarely useful in practice

TC mentioned that it may be useful to keep the attribute around so that crates could have cargo features for enabling constness without having to duplicate the item.

many traits have one or more of super traits, assoc type bounds, or const where bounds, making that not useful for them.

see https://github.com/rust-lang/rust/pull/148683/