1For any given trait `Trait` there may be a related _type_ called the _trait2object type_ which is typically written as `dyn Trait`. In earlier editions of3Rust, trait object types were written as plain `Trait` (just the name of the4trait, written in type positions) but this was a bit too confusing, so we now5write `dyn Trait`.67Some traits are not allowed to be used as trait object types. The traits that8are allowed to be used as trait object types are called "dyn-compatible"[^1]9traits. Attempting to use a trait object type for a trait that is not10dyn-compatible will trigger error E0038.1112Two general aspects of trait object types give rise to the restrictions:1314  1. Trait object types are dynamically sized types (DSTs), and trait objects of15     these types can only be accessed through pointers, such as `&dyn Trait` or16     `Box<dyn Trait>`. The size of such a pointer is known, but the size of the17     `dyn Trait` object pointed-to by the pointer is _opaque_ to code working18     with it, and different trait objects with the same trait object type may19     have different sizes.2021  2. The pointer used to access a trait object is paired with an extra pointer22     to a "virtual method table" or "vtable", which is used to implement dynamic23     dispatch to the object's implementations of the trait's methods. There is a24     single such vtable for each trait implementation, but different trait25     objects with the same trait object type may point to vtables from different26     implementations.2728The specific conditions that violate dyn-compatibility follow, most of which29relate to missing size information and vtable polymorphism arising from these30aspects.3132[^1]: Formerly known as "object-safe".3334### The trait requires `Self: Sized`3536Traits that are declared as `Trait: Sized` or which otherwise inherit a37constraint of `Self:Sized` are not dyn-compatible.3839The reasoning behind this is somewhat subtle. It derives from the fact that Rust40requires (and defines) that every trait object type `dyn Trait` automatically41implements `Trait`. Rust does this to simplify error reporting and ease42interoperation between static and dynamic polymorphism. For example, this code43works:4445```46trait Trait {47}4849fn static_foo<T:Trait + ?Sized>(b: &T) {50}5152fn dynamic_bar(a: &dyn Trait) {53    static_foo(a)54}55```5657This code works because `dyn Trait`, if it exists, always implements `Trait`.5859However as we know, any `dyn Trait` is also unsized, and so it can never60implement a sized trait like `Trait:Sized`. So, rather than allow an exception61to the rule that `dyn Trait` always implements `Trait`, Rust chooses to prohibit62such a `dyn Trait` from existing at all.6364Only unsized traits are considered dyn-compatible.6566Generally, `Self: Sized` is used to indicate that the trait should not be used67as a trait object. If the trait comes from your own crate, consider removing68this restriction.6970### Method references the `Self` type in its parameters or return type7172This happens when a trait has a method like the following:7374```75trait Trait {76    fn foo(&self) -> Self;77}7879impl Trait for String {80    fn foo(&self) -> Self {81        "hi".to_owned()82    }83}8485impl Trait for u8 {86    fn foo(&self) -> Self {87        188    }89}90```9192(Note that `&self` and `&mut self` are okay, it's additional `Self` types which93cause this problem.)9495In such a case, the compiler cannot predict the return type of `foo()` in a96situation like the following:9798```compile_fail,E003899trait Trait {100    fn foo(&self) -> Self;101}102103fn call_foo(x: Box<dyn Trait>) {104    let y = x.foo(); // What type is y?105    // ...106}107```108109If only some methods aren't dyn-compatible, you can add a `where Self: Sized`110bound on them to mark them as explicitly unavailable to trait objects. The111functionality will still be available to all other implementers, including112`Box<dyn Trait>` which is itself sized (assuming you `impl Trait for Box<dyn113Trait>`).114115```116trait Trait {117    fn foo(&self) -> Self where Self: Sized;118    // more functions119}120```121122Now, `foo()` can no longer be called on a trait object, but you will now be123allowed to make a trait object, and that will be able to call any dyn-compatible124methods. With such a bound, one can still call `foo()` on types implementing125that trait that aren't behind trait objects.126127### Method has generic type parameters128129As mentioned before, trait objects contain pointers to method tables. So, if we130have:131132```133trait Trait {134    fn foo(&self);135}136137impl Trait for String {138    fn foo(&self) {139        // implementation 1140    }141}142143impl Trait for u8 {144    fn foo(&self) {145        // implementation 2146    }147}148// ...149```150151At compile time each implementation of `Trait` will produce a table containing152the various methods (and other items) related to the implementation, which will153be used as the virtual method table for a `dyn Trait` object derived from that154implementation.155156This works fine, but when the method gains generic parameters, we can have a157problem.158159Usually, generic parameters get _monomorphized_. For example, if I have160161```162fn foo<T>(x: T) {163    // ...164}165```166167The machine code for `foo::<u8>()`, `foo::<bool>()`, `foo::<String>()`, or any168other instantiation is different. Hence the compiler generates the169implementation on-demand. If you call `foo()` with a `bool` parameter, the170compiler will only generate code for `foo::<bool>()`. When we have additional171type parameters, the number of monomorphized implementations the compiler172generates does not grow drastically, since the compiler will only generate an173implementation if the function is called with fully concrete arguments174(i.e., arguments which do not contain any generic parameters).175176However, with trait objects we have to make a table containing _every_ object177that implements the trait. Now, if it has type parameters, we need to add178implementations for every type that implements the trait, and there could179theoretically be an infinite number of types.180181For example, with:182183```184trait Trait {185    fn foo<T>(&self, on: T);186    // more methods187}188189impl Trait for String {190    fn foo<T>(&self, on: T) {191        // implementation 1192    }193}194195impl Trait for u8 {196    fn foo<T>(&self, on: T) {197        // implementation 2198    }199}200201// 8 more implementations202```203204Now, if we have the following code:205206```compile_fail,E0038207# trait Trait { fn foo<T>(&self, on: T); }208# impl Trait for String { fn foo<T>(&self, on: T) {} }209# impl Trait for u8 { fn foo<T>(&self, on: T) {} }210# impl Trait for bool { fn foo<T>(&self, on: T) {} }211# // etc.212fn call_foo(thing: Box<dyn Trait>) {213    thing.foo(true); // this could be any one of the 8 types above214    thing.foo(1);215    thing.foo("hello");216}217```218219We don't just need to create a table of all implementations of all methods of220`Trait`, we need to create such a table, for each different type fed to221`foo()`. In this case this turns out to be (10 types implementing `Trait`)\*(3222types being fed to `foo()`) = 30 implementations!223224With real world traits these numbers can grow drastically.225226To fix this, it is suggested to use a `where Self: Sized` bound similar to the227fix for the sub-error above if you do not intend to call the method with type228parameters:229230```231trait Trait {232    fn foo<T>(&self, on: T) where Self: Sized;233    // more methods234}235```236237If this is not an option, consider replacing the type parameter with another238trait object (e.g., if `T: OtherTrait`, use `on: Box<dyn OtherTrait>`). If the239number of types you intend to feed to this method is limited, consider manually240listing out the methods of different types.241242### Method has no receiver243244Methods that do not take a `self` parameter can't be called since there won't be245a way to get a pointer to the method table for them.246247```248trait Foo {249    fn foo() -> u8;250}251```252253This could be called as `<Foo as Foo>::foo()`, which would not be able to pick254an implementation.255256Adding a `Self: Sized` bound to these methods will generally make this compile.257258```259trait Foo {260    fn foo() -> u8 where Self: Sized;261}262```263264### Trait contains associated constants265266Just like static functions, associated constants aren't stored on the method267table. If the trait or any subtrait contain an associated constant, they are not268dyn compatible.269270```compile_fail,E0038271trait Foo {272    const X: i32;273}274275impl dyn Foo {}276```277278A simple workaround is to use a helper method instead:279280```281trait Foo {282    fn x(&self) -> i32;283}284```285286### Trait uses `Self` as a type parameter in the supertrait listing287288This is similar to the second sub-error, but subtler. It happens in situations289like the following:290291```compile_fail,E0038292trait Super<A: ?Sized> {}293294trait Trait: Super<Self> {295}296297struct Foo;298299impl Super<Foo> for Foo{}300301impl Trait for Foo {}302303fn main() {304    let x: Box<dyn Trait>;305}306```307308Here, the supertrait might have methods as follows:309310```311trait Super<A: ?Sized> {312    fn get_a(&self) -> &A; // note that this is dyn-compatible!313}314```315316If the trait `Trait` was deriving from something like `Super<String>` or317`Super<T>` (where `Foo` itself is `Foo<T>`), this is okay, because given a type318`get_a()` will definitely return an object of that type.319320However, if it derives from `Super<Self>`, even though `Super` is321dyn-compatible, the method `get_a()` would return an object of unknown type when322called on the function. `Self` type parameters let us make dyn-compatible traits323no longer compatible, so they are forbidden when specifying supertraits.324325There's no easy fix for this. Generally, code will need to be refactored so that326you no longer need to derive from `Super<Self>`.