1 For any given trait `Trait` there may be a related _type_ called the _trait
2 object type_ which is typically written as `dyn Trait`. In earlier editions of
3 Rust, trait object types were written as plain `Trait` (just the name of the
4 trait, written in type positions) but this was a bit too confusing, so we now
7 Some traits are not allowed to be used as trait object types. The traits that
8 are allowed to be used as trait object types are called "object-safe" traits.
9 Attempting to use a trait object type for a trait that is not object-safe will
12 Two general aspects of trait object types give rise to the restrictions:
14 1. Trait object types are dynamically sized types (DSTs), and trait objects of
15 these types can only be accessed through pointers, such as `&dyn Trait` or
16 `Box<dyn Trait>`. The size of such a pointer is known, but the size of the
17 `dyn Trait` object pointed-to by the pointer is _opaque_ to code working
18 with it, and different trait objects with the same trait object type may
21 2. The pointer used to access a trait object is paired with an extra pointer
22 to a "virtual method table" or "vtable", which is used to implement dynamic
23 dispatch to the object's implementations of the trait's methods. There is a
24 single such vtable for each trait implementation, but different trait
25 objects with the same trait object type may point to vtables from different
28 The specific conditions that violate object-safety follow, most of which relate
29 to missing size information and vtable polymorphism arising from these aspects.
31 ### The trait requires `Self: Sized`
33 Traits that are declared as `Trait: Sized` or which otherwise inherit a
34 constraint of `Self:Sized` are not object-safe.
36 The reasoning behind this is somewhat subtle. It derives from the fact that Rust
37 requires (and defines) that every trait object type `dyn Trait` automatically
38 implements `Trait`. Rust does this to simplify error reporting and ease
39 interoperation between static and dynamic polymorphism. For example, this code
46 fn static_foo<T:Trait + ?Sized>(b: &T) {
49 fn dynamic_bar(a: &dyn Trait) {
54 This code works because `dyn Trait`, if it exists, always implements `Trait`.
56 However as we know, any `dyn Trait` is also unsized, and so it can never
57 implement a sized trait like `Trait:Sized`. So, rather than allow an exception
58 to the rule that `dyn Trait` always implements `Trait`, Rust chooses to prohibit
59 such a `dyn Trait` from existing at all.
61 Only unsized traits are considered object-safe.
63 Generally, `Self: Sized` is used to indicate that the trait should not be used
64 as a trait object. If the trait comes from your own crate, consider removing
67 ### Method references the `Self` type in its parameters or return type
69 This happens when a trait has a method like the following:
73 fn foo(&self) -> Self;
76 impl Trait for String {
77 fn foo(&self) -> Self {
83 fn foo(&self) -> Self {
89 (Note that `&self` and `&mut self` are okay, it's additional `Self` types which
92 In such a case, the compiler cannot predict the return type of `foo()` in a
93 situation like the following:
97 fn foo(&self) -> Self;
100 fn call_foo(x: Box<dyn Trait>) {
101 let y = x.foo(); // What type is y?
106 If only some methods aren't object-safe, you can add a `where Self: Sized` bound
107 on them to mark them as explicitly unavailable to trait objects. The
108 functionality will still be available to all other implementers, including
109 `Box<dyn Trait>` which is itself sized (assuming you `impl Trait for Box<dyn
114 fn foo(&self) -> Self where Self: Sized;
119 Now, `foo()` can no longer be called on a trait object, but you will now be
120 allowed to make a trait object, and that will be able to call any object-safe
121 methods. With such a bound, one can still call `foo()` on types implementing
122 that trait that aren't behind trait objects.
124 ### Method has generic type parameters
126 As mentioned before, trait objects contain pointers to method tables. So, if we
134 impl Trait for String {
148 At compile time each implementation of `Trait` will produce a table containing
149 the various methods (and other items) related to the implementation, which will
150 be used as the virtual method table for a `dyn Trait` object derived from that
153 This works fine, but when the method gains generic parameters, we can have a
156 Usually, generic parameters get _monomorphized_. For example, if I have
164 The machine code for `foo::<u8>()`, `foo::<bool>()`, `foo::<String>()`, or any
165 other type substitution is different. Hence the compiler generates the
166 implementation on-demand. If you call `foo()` with a `bool` parameter, the
167 compiler will only generate code for `foo::<bool>()`. When we have additional
168 type parameters, the number of monomorphized implementations the compiler
169 generates does not grow drastically, since the compiler will only generate an
170 implementation if the function is called with unparameterized substitutions
171 (i.e., substitutions where none of the substituted types are themselves
174 However, with trait objects we have to make a table containing _every_ object
175 that implements the trait. Now, if it has type parameters, we need to add
176 implementations for every type that implements the trait, and there could
177 theoretically be an infinite number of types.
183 fn foo<T>(&self, on: T);
187 impl Trait for String {
188 fn foo<T>(&self, on: T) {
194 fn foo<T>(&self, on: T) {
199 // 8 more implementations
202 Now, if we have the following code:
204 ```compile_fail,E0038
205 # trait Trait { fn foo<T>(&self, on: T); }
206 # impl Trait for String { fn foo<T>(&self, on: T) {} }
207 # impl Trait for u8 { fn foo<T>(&self, on: T) {} }
208 # impl Trait for bool { fn foo<T>(&self, on: T) {} }
210 fn call_foo(thing: Box<dyn Trait>) {
211 thing.foo(true); // this could be any one of the 8 types above
217 We don't just need to create a table of all implementations of all methods of
218 `Trait`, we need to create such a table, for each different type fed to
219 `foo()`. In this case this turns out to be (10 types implementing `Trait`)\*(3
220 types being fed to `foo()`) = 30 implementations!
222 With real world traits these numbers can grow drastically.
224 To fix this, it is suggested to use a `where Self: Sized` bound similar to the
225 fix for the sub-error above if you do not intend to call the method with type
230 fn foo<T>(&self, on: T) where Self: Sized;
235 If this is not an option, consider replacing the type parameter with another
236 trait object (e.g., if `T: OtherTrait`, use `on: Box<dyn OtherTrait>`). If the
237 number of types you intend to feed to this method is limited, consider manually
238 listing out the methods of different types.
240 ### Method has no receiver
242 Methods that do not take a `self` parameter can't be called since there won't be
243 a way to get a pointer to the method table for them.
251 This could be called as `<Foo as Foo>::foo()`, which would not be able to pick
254 Adding a `Self: Sized` bound to these methods will generally make this compile.
258 fn foo() -> u8 where Self: Sized;
262 ### Trait contains associated constants
264 Just like static functions, associated constants aren't stored on the method
265 table. If the trait or any subtrait contain an associated constant, they cannot
266 be made into an object.
268 ```compile_fail,E0038
276 A simple workaround is to use a helper method instead:
284 ### Trait uses `Self` as a type parameter in the supertrait listing
286 This is similar to the second sub-error, but subtler. It happens in situations
289 ```compile_fail,E0038
290 trait Super<A: ?Sized> {}
292 trait Trait: Super<Self> {
297 impl Super<Foo> for Foo{}
299 impl Trait for Foo {}
302 let x: Box<dyn Trait>;
306 Here, the supertrait might have methods as follows:
309 trait Super<A: ?Sized> {
310 fn get_a(&self) -> &A; // note that this is object safe!
314 If the trait `Trait` was deriving from something like `Super<String>` or
315 `Super<T>` (where `Foo` itself is `Foo<T>`), this is okay, because given a type
316 `get_a()` will definitely return an object of that type.
318 However, if it derives from `Super<Self>`, even though `Super` is object safe,
319 the method `get_a()` would return an object of unknown type when called on the
320 function. `Self` type parameters let us make object safe traits no longer safe,
321 so they are forbidden when specifying supertraits.
323 There's no easy fix for this. Generally, code will need to be refactored so that
324 you no longer need to derive from `Super<Self>`.