# How to define a user-defined trait that behaves likes that Copy imposes requirements to the implementation? **URL:** \ **Category:** language design\ **Created:** [February 22, 2023, 6:24am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395 "2023-02-22T06:24:03Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![xmh0511](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/xmh0511/32/9874_2.png) [@xmh0511](https://internals.rust-lang.org/u/xmh0511)\ **Post date:** [February 22, 2023, 6:24am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/1 "2023-02-22T06:24:03Z")
If one type wants to implement `Copy`, the `Copy` trait would impose the requirements that all of its fields of that type have implemented `Copy`. Currently, we seem cannot user-define such a trait that imposes similar requirements to its implementation. ```rust trait deep-check A{} struct B{ v: i32 } impl A for B{} // it would be an error if `i32` didn't implement `A` ``` ---
**Author:** ![jjpe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jjpe/32/9779_2.png) [@jjpe](https://internals.rust-lang.org/u/jjpe)\ **Post date:** [February 22, 2023, 8:13am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/2 "2023-02-22T08:13:16Z")
To answer the question: you can't. Support for Copy is deeply baked into the compiler. In addition, arguably by design, in general traits shouldn't affect items that are outside the purview of the current `impl Trait for Type` item. Which is to say, such an impl should only be allowed to affect the semantics of `Type` values, but not the definition (i.e. struct or enum item) of either `Type` or `Trait`. Allowing that (which is what you seem to be asking for). What might help though is an attribute macro, or maybe even a derive macro. When placed on a struct or enum, it can inspect the definition of that type definition and generate code based on that. So you could generate an impl block for the type with the bounds you want. ---
**Author:** ![xmh0511](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/xmh0511/32/9874_2.png) [@xmh0511](https://internals.rust-lang.org/u/xmh0511)\ **Post date:** [February 22, 2023, 9:21am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/3 "2023-02-22T09:21:41Z")
attribute macro is unhelpful if the impl type is in the other crate. ```rust trait deep-check A{} impl A for xxx::Type{ // we want to check whether the contained type in `Type` implements A } ``` ---
**Author:** ![Nemo157](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nemo157/32/11585_2.png) [@Nemo157](https://internals.rust-lang.org/u/Nemo157)\ **Post date:** [February 22, 2023, 9:52am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/4 "2023-02-22T09:52:58Z")
The other main option is to do something like `Send`: make the trait `unsafe` and require the user to assert that all fields are valid when implementing it. You could then potentially write a derive that checks that for the user. One example of doing this is `bytemuck`s traits + derives, e.g. [AnyBitPattern in bytemuck - Rust](https://docs.rs/bytemuck/latest/bytemuck/derive.AnyBitPattern.html). ---
**Author:** ![xmh0511](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/xmh0511/32/9874_2.png) [@xmh0511](https://internals.rust-lang.org/u/xmh0511)\ **Post date:** [February 22, 2023, 9:59am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/5 "2023-02-22T09:59:31Z")
Since it is a common usage, why do we not add this function to the core language? ---
**Author:** ![zirconium-n](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/zirconium-n/32/9078_2.png) [@zirconium-n](https://internals.rust-lang.org/u/zirconium-n)\ **Post date:** [February 22, 2023, 10:32am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/6 "2023-02-22T10:32:16Z")
Because it still has undecided design problems. See [Tracking Issue for auto traits (auto\_traits) -- formerly called opt-in built-in traits (optin\_builtin\_traits) · Issue #13231 · rust-lang/rust · GitHub](https://github.com/rust-lang/rust/issues/13231) ---
**Author:** ![xmh0511](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/xmh0511/32/9874_2.png) [@xmh0511](https://internals.rust-lang.org/u/xmh0511)\ **Post date:** [February 23, 2023, 5:28am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/7 "2023-02-23T05:28:16Z")
Yes, but they are a bit different. `auto trait` will be **automatically** implemented for the type if these types therein satisfy the trait. However, `Copy` is not an auto trait, this issue is, when we manually implement the trait for a particular type, the prerequires are these types therein shall satisfy that trait. ---
**Author:** ![zirconium-n](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/zirconium-n/32/9078_2.png) [@zirconium-n](https://internals.rust-lang.org/u/zirconium-n)\ **Post date:** [February 23, 2023, 11:06am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/8 "2023-02-23T11:06:13Z")
Hmm I think I get what you mean now. I think the usage is not common enough to justify the inclusion. The only time I find this helpful is writing ffi-safe struct and hope there's a trait to ensure I did not break ffi safety. ---
**Author:** ![scottmcm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/scottmcm/32/2355_2.png) [@scottmcm](https://internals.rust-lang.org/u/scottmcm)\ **Post date:** [February 24, 2023, 2:15am UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/9 "2023-02-24T02:15:15Z")
The big problem with auto traits is ecosystem impact. There's no realistic way for people to opt _out_ of every random auto trait that other people invent. Thus traits in the ecosystem are generally better as ordinary traits, with a derive that does the right thing. Getting everyone to integrate with them is more annoying, but at least it's not unsound. ---
**Author:** ![eggyal](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/eggyal/32/7947_2.png) [@eggyal](https://internals.rust-lang.org/u/eggyal)\ **Post date:** [February 27, 2023, 11:15pm UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/10 "2023-02-27T23:15:36Z")
Traits provide consumers with an abstraction, such that they do not care for the details of the implementation other than that it meets the expected contract. What do I, as a consumer of your trait, care whether the fields of your implementing struct also implement the trait? Either those fields are private and I don't care about them at all, or they are public and their type is known to me (together with their trait implementations, if any). `Copy` is different in that the _compiler_ is its consumer: when a type is `Copy`, the compiler may treat it differently—and for that to be sound, the compiler ensures that all fields are also `Copy`. I guess I'm struggling to see how this could be useful. Perhaps if you could set out a concrete use case...? ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [May 28, 2023, 11:15pm UTC](https://internals.rust-lang.org/t/how-to-define-a-user-defined-trait-that-behaves-likes-that-copy-imposes-requirements-to-the-implementation/18395/11 "2023-05-28T23:15:45Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.