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

easy solution: `const impl` blocks that make all methods within it const and are allowed to have `[const]` trait bounds

weird but convenient solution: `impl` blocks can have `[const]` bounds which are treated as normal bounds in non-const fn where they make no sense

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

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] PaPartialEq`

### 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

### 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
}