Trait Objects for Using Values of Different Types
In Chapter 8, we talked about a limitation of vectors is that vectors can only
store elements of one type. We had an example in Listing 8-1 where we defined a
SpreadsheetCell
enum that had variants to hold integers, floats, and text so
that we could store different types of data in each cell and still have a
vector represent a row of cells. This works for cases in which the kinds of
things we want to be able to treat interchangeably are a fixed set of types that
we know when our code gets compiled.
Sometimes we want the set of types that we use to be extensible by the
programmers who use our library. For example, many Graphical User Interface
tools have a concept of a list of items that get drawn on the screen by
iterating through the list and calling a draw
method on each of the items.
We're going to create a library crate containing the structure of a GUI library
called rust_gui
. Our GUI library could include some types for people to use,
such as Button
or TextField
. Programmers that use rust_gui
will want to
create more types that can be drawn on the screen: one programmer might add an
Image
, while another might add a SelectBox
. We're not going to implement a
fully-fledged GUI library in this chapter, but we will show how the pieces
would fit together.
When we're writing the rust_gui
library, we don't know all the types that
other programmers will want to create, so we can't define an enum
containing
all the types. What we do know is that rust_gui
needs to be able to keep
track of a bunch of values of all these different types, and it needs to be
able to call a draw
method on each of these values. Our GUI library doesn't
need to know what will happen exactly when we call the draw
method, just that
the value will have that method available for us to call.
In a language with inheritance, we might define a class named Component
that
has a method named draw
on it. The other classes like Button
, Image
, and
SelectBox
would inherit from Component
and thus inherit the draw
method.
They could each override the draw
method to define their custom behavior, but
the framework could treat all of the types as if they were Component
instances and call draw
on them.
Defining a Trait for the Common Behavior
In Rust, though, we can define a trait that we'll name Draw
and that will
have one method named draw
. Then we can define a vector that takes a trait
object, which is a trait behind some sort of pointer, such as a &
reference
or a Box<T>
smart pointer.
We mentioned that we don't call structs and enums "objects" to distinguish
structs and enums from other languages' objects. The data in the struct or enum
fields and the behavior in impl
blocks is separated, as opposed to other
languages that have data and behavior combined into one concept called an
object. Trait objects are more like objects in other languages, in the sense
that they combine the data made up of the pointer to a concrete object with the
behavior of the methods defined in the trait. However, trait objects are
different from objects in other languages because we can't add data to a trait
object. Trait objects aren't as generally useful as objects in other languages:
their purpose is to allow abstraction across common behavior.
A trait defines behavior that we need in a given situation. We can then use a
trait as a trait object in places where we would use a concrete type or a
generic type. Rust's type system will ensure that any value we substitute in
for the trait object will implement the methods of the trait. Then we don't
need to know all the possible types at compile time, and we can treat all the
instances the same way. Listing 17-3 shows how to define a trait named Draw
with one method named draw
:
Filename: src/lib.rs
pub trait Draw {
fn draw(&self);
}
This should look familiar since we talked about how to define traits in
Chapter 10. Next comes something new: Listing 17-4 has the definition of a
struct named Screen
that holds a vector named components
that are of type
Box<Draw>
. That Box<Draw>
is a trait object: it's a stand-in for any type
inside a Box
that implements the Draw
trait.
Filename: src/lib.rs
# pub trait Draw {
# fn draw(&self);
# }
#
pub struct Screen {
pub components: Vec<Box<Draw>>,
}
On the Screen
struct, we'll define a method named run
, which will call the
draw
method on each of its components
as shown in Listing 17-5:
Filename: src/lib.rs
# pub trait Draw {
# fn draw(&self);
# }
#
# pub struct Screen {
# pub components: Vec<Box<Draw>>,
# }
#
impl Screen {
pub fn run(&self) {
for component in self.components.iter() {
component.draw();
}
}
}
This is different than defining a struct that uses a generic type parameter
with trait bounds. A generic type parameter can only be substituted with one
concrete type at a time, while trait objects allow for multiple concrete types
to fill in for the trait object at runtime. For example, we could have defined
the Screen
struct using a generic type and a trait bound as in Listing 17-6:
Filename: src/lib.rs
# pub trait Draw {
# fn draw(&self);
# }
#
pub struct Screen<T: Draw> {
pub components: Vec<T>,
}
impl<T> Screen<T>
where T: Draw {
pub fn run(&self) {
for component in self.components.iter() {
component.draw();
}
}
}
This only lets us have a Screen
instance that has a list of components that
are all of type Button
or all of type TextField
. If you'll only ever have
homogeneous collections, using generics and trait bounds is preferable since
the definitions will be monomorphized at compile time to use the concrete types.
With the definition of Screen
that holds a component list of trait objects in
Vec<Box<Draw>>
instead, one Screen
instance can hold a Vec
that contains
a Box<Button>
as well as a Box<TextField>
. Let's see how that works, and
then talk about the runtime performance implications.
Implementations of the Trait from Us or Library Users
Now to add some types that implement the Draw
trait. We're going to provide
the Button
type, and again, actually implementing a GUI library is out of
scope of this book, so the draw
method won't have any useful implementation
in its body. To imagine what the implementation might look like, a Button
struct might have fields for width
, height
, and label
, as shown in
Listing 17-7:
Filename: src/lib.rs
# pub trait Draw {
# fn draw(&self);
# }
#
pub struct Button {
pub width: u32,
pub height: u32,
pub label: String,
}
impl Draw for Button {
fn draw(&self) {
// Code to actually draw a button
}
}
The width
, height
, and label
fields on Button
will differ from other
components, such as a TextField
type that might have width
, height
,
label
, and placeholder
fields instead. Each of the types that we want to be
able to draw on the screen will implement the Draw
trait with different code
in the draw
method that defines how to draw that type like Button
has here
(without any actual GUI code that's out of scope of this chapter). In addition
to implementing the Draw
trait, Button
might also have another impl
block
containing methods having to do with what happens if the button is clicked.
These kinds of methods won't apply to types like TextField
.
Someone using our library has decided to implement a SelectBox
struct that
has width
, height
, and options
fields. They implement the Draw
trait on
the SelectBox
type as well, as shown in Listing 17-8:
Filename: src/main.rs
extern crate rust_gui;
use rust_gui::Draw;
struct SelectBox {
width: u32,
height: u32,
options: Vec<String>,
}
impl Draw for SelectBox {
fn draw(&self) {
// Code to actually draw a select box
}
}
The user of our library can now write their main
function to create a
Screen
instance and add a SelectBox
and a Button
to the screen by putting
each in a Box<T>
to become a trait object. They can then call the run
method on the Screen
instance, which will call draw
on each of the
components. Listing 17-9 shows this implementation:
Filename: src/main.rs
use rust_gui::{Screen, Button};
fn main() {
let screen = Screen {
components: vec![
Box::new(SelectBox {
width: 75,
height: 10,
options: vec![
String::from("Yes"),
String::from("Maybe"),
String::from("No")
],
}),
Box::new(Button {
width: 50,
height: 10,
label: String::from("OK"),
}),
],
};
screen.run();
}
Even though we didn't know that someone would add the SelectBox
type someday,
our Screen
implementation was able to operate on the SelectBox
and draw it
because SelectBox
implements the Draw
type, which means it implements the
draw
method.
Only being concerned with the messages a value responds to, rather than the
value's concrete type, is similar to a concept called duck typing in
dynamically typed languages: if it walks like a duck, and quacks like a duck,
then it must be a duck! In the implementation of run
on Screen
in Listing
17-5, run
doesn't need to know what the concrete type of each component is.
It doesn't check to see if a component is an instance of a Button
or a
SelectBox
, it just calls the draw
method on the component. By specifying
Box<Draw>
as the type of the values in the components
vector, we've defined
that Screen
needs values that we can call the draw
method on.
The advantage with using trait objects and Rust's type system to do duck typing is that we never have to check that a value implements a particular method at runtime or worry about getting errors if a value doesn't implement a method but we call it. Rust won't compile our code if the values don't implement the traits that the trait objects need.
For example, Listing 17-10 shows what happens if we try to create a Screen
with a String
as a component:
Filename: src/main.rs
extern crate rust_gui;
use rust_gui::Draw;
fn main() {
let screen = Screen {
components: vec![
Box::new(String::from("Hi")),
],
};
screen.run();
}
We'll get this error because String
doesn't implement the Draw
trait:
error[E0277]: the trait bound `std::string::String: Draw` is not satisfied
-->
|
4 | Box::new(String::from("Hi")),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Draw` is not
implemented for `std::string::String`
|
= note: required for the cast to the object type `Draw`
This lets us know that either we're passing something we didn't mean to pass to
Screen
and we should pass a different type, or we should implement Draw
on
String
so that Screen
is able to call draw
on it.
Trait Objects Perform Dynamic Dispatch
Recall in Chapter 10 when we discussed the process of monomorphization that the compiler performs when we use trait bounds on generics: the compiler generates non-generic implementations of functions and methods for each concrete type that we use in place of a generic type parameter. The code that results from monomorphization is doing static dispatch: when the method is called, the code that goes with that method call has been determined at compile time, and looking up that code is very fast.
When we use trait objects, the compiler can't perform monomorphization because we don't know all the types that might be used with the code. Instead, Rust keeps track of the code that might be used when a method is called and figures out at runtime which code needs to be used for a particular method call. This is known as dynamic dispatch, and there's a runtime cost when this lookup happens. Dynamic dispatch also prevents the compiler from choosing to inline a method's code, which prevents some optimizations. We did get extra flexibility in the code that we wrote and were able to support, though, so it's a tradeoff to consider.
Object Safety is Required for Trait Objects
Not all traits can be made into trait objects; only object safe traits can. A trait is object safe as long as both of the following are true:
- The trait does not require
Self
to beSized
- All of the trait's methods are object safe.
Self
is a keyword that is an alias for the type that we're implementing
traits or methods on. Sized
is a marker trait like the Send
and Sync
traits that we talked about in Chapter 16. Sized
is automatically implemented
on types that have a known size at compile time, such as i32
and references.
Types that do not have a known size include slices ([T]
) and trait objects.
Sized
is an implicit trait bound on all generic type parameters by default.
Most useful operations in Rust require a type to be Sized
, so making Sized
a default requirement on trait bounds means we don't have to write T: Sized
with most every use of generics. If we want to be able to use a trait on
slices, however, we need to opt out of the Sized
trait bound, and we can do
that by specifying T: ?Sized
as a trait bound.
Traits have a default bound of Self: ?Sized
, which means that they can be
implemented on types that may or may not be Sized
. If we create a trait Foo
that opts out of the Self: ?Sized
bound, that would look like the following:
trait Foo: Sized {
fn some_method(&self);
}
The trait Sized
is now a super trait of trait Foo
, which means trait
Foo
requires types that implement Foo
(that is, Self
) to be Sized
.
We're going to talk about super traits in more detail in Chapter 19.
The reason a trait like Foo
that requires Self
to be Sized
is not allowed
to be a trait object is that it would be impossible to implement the trait
Foo
for the trait object Foo
: trait objects aren't sized, but Foo
requires Self
to be Sized
. A type can't be both sized and unsized at the
same time!
For the second object safety requirement that says all of a trait's methods must be object safe, a method is object safe if either:
- It requires
Self
to beSized
or - It meets all three of the following:
- It must not have any generic type parameters
- Its first argument must be of type
Self
or a type that dereferences to the Self type (that is, it must be a method rather than an associated function and haveself
,&self
, or&mut self
as the first argument) - It must not use
Self
anywhere else in the signature except for the first argument
Those rules are a bit formal, but think of it this way: if your method requires
the concrete Self
type somewhere in its signature, but an object forgets the
exact type that it is, there's no way that the method can use the original
concrete type that it's forgotten. Same with generic type parameters that are
filled in with concrete type parameters when the trait is used: the concrete
types become part of the type that implements the trait. When the type is
erased by the use of a trait object, there's no way to know what types to fill
in the generic type parameters with.
An example of a trait whose methods are not object safe is the standard
library's Clone
trait. The signature for the clone
method in the Clone
trait looks like this:
pub trait Clone {
fn clone(&self) -> Self;
}
String
implements the Clone
trait, and when we call the clone
method on
an instance of String
we get back an instance of String
. Similarly, if we
call clone
on an instance of Vec
, we get back an instance of Vec
. The
signature of clone
needs to know what type will stand in for Self
, since
that's the return type.
If we try to implement Clone
on a trait like the Draw
trait from Listing
17-3, we wouldn't know whether Self
would end up being a Button
, a
SelectBox
, or some other type that will implement the Draw
trait in the
future.
The compiler will tell you if you're trying to do something that violates the
rules of object safety in regards to trait objects. For example, if we had
tried to implement the Screen
struct in Listing 17-4 to hold types that
implement the Clone
trait instead of the Draw
trait, like this:
pub struct Screen {
pub components: Vec<Box<Clone>>,
}
We'll get this error:
error[E0038]: the trait `std::clone::Clone` cannot be made into an object
-->
|
2 | pub components: Vec<Box<Clone>>,
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::clone::Clone` cannot be
made into an object
|
= note: the trait cannot require that `Self : Sized`