How do I specify that a struct field must implement a trait?

by

This is the tricky point of trait objects, you need to be very explicit about who owns the underlying object.

Indeed, when you use a trait as a type, the underlying object must be stored somewhere, as trait objects are in fact references to an object implementing the given trait. This is why you cannot have a bare MyTrait as a type, it must be either a reference &MyTrait or a box Box<MyTrait>.

With references

The first method you tried was was with a reference and the compiler complained about a missing lifetime specifier :

struct Bar {
   foo : &Foo,
}

The problem is, a reference doesn’t own the underlying object, and an other object or scope must own it somewhere: you are only borrowing it. And thus, the compiler need information about how long this reference will be valid: if the underlying object was destroyed, your Bar instance would have a reference to freed memory, which is forbidden !

The idea here is to add lifetimes:

struct Bar<'a> {
   foo : &'a (Foo + 'a),
}

What you are saying here to the compiler is : “My Bar object cannot outlive the Foo reference inside it”. You have to specify the lifetime two times : once for the lifetime of the reference, and once for the trait object itself, because traits can be implemented for references, and if the underlying object is a reference, you must specify its lifetime as well.

On special case would be writing:

struct Bar<'a> {
   foo : &'a (Foo + 'static),
}

In this case, the 'static requires that the underlying object must be a real struct, or a &'static reference, but other references won’t be allowed.

Also, to build your object, you will have to give it a reference to an other object you store yourself.

You end up with something like this :

trait Foo {}

struct MyFoo;

impl Foo for MyFoo {}

struct Bar<'a> {
    foo: &'a (Foo + 'a),
}

impl<'a> Bar<'a> {
    fn new(the_foo: &'a Foo) -> Bar<'a> {
        Bar { foo: the_foo }
    }

    fn get_foo(&'a self) -> &'a Foo {
        self.foo
    }
}

fn main() {
    let myfoo = MyFoo;
    let mybar = Bar::new(&myfoo as &Foo);
}

With Boxes

A Box contrarily owns its content, thus it allows you to give ownership of the underlying object to your Bar struct. Yet, as this underlying object could be a reference, you need to specify a lifetime as well :

struct Bar<'a> {
    foo: Box<Foo + 'a>
}

If your know that the underlying object cannot be a reference, you can also write:

struct Bar {
    foo: Box<Foo + 'static>
}

and the lifetime problem disappears completely.

The construction of the object is thus similar, but simpler as you don’t need to store the underlying object yourself, it is handled by the box :

trait Foo {}

struct MyFoo;

impl Foo for MyFoo {}

struct Bar<'a> {
    foo: Box<Foo + 'a>,
}

impl<'a> Bar<'a> {
    fn new(the_foo: Box<Foo + 'a>) -> Bar<'a> {
        Bar { foo: the_foo }
    }

    fn get_foo(&'a self) -> &'a Foo {
        &*self.foo
    }
}

fn main() {
    let mybar = Bar::new(box MyFoo as Box<Foo>);
}

In this case, the 'static version would be :

trait Foo {}

struct MyFoo;

impl Foo for MyFoo {}

struct Bar {
    foo: Box<Foo + 'static>,
}

impl Bar {
    fn new(the_foo: Box<Foo + 'static>) -> Bar {
        Bar { foo: the_foo }
    }

    fn get_foo<'a>(&'a self) -> &'a Foo {
        &*self.foo
    }
}

fn main() {
    let mybar = Bar::new(box MyFoo as Box<Foo>);
    let x = mybar.get_foo();
}

With the bare value

To answer your last question :

Whats the implication of removing the & and just using self?

If a method has a definition like this :

fn unwrap(self) {}

It means it will consume your object in the process, and after calling bar.unwrap(), you won’t be able to use bar any longer.

It is a process used generally to give back ownership of the data your struct owned. You’ll meet a lot of unwrap() functions in the standard library.

More Related Contents:

  1. Traits and Rust
  2. How to get a reference to a concrete type from a trait object?
  3. Why can impl trait not be used to return multiple / conditional types?
  4. How do I implement a trait I don’t own for a type I don’t own?
  5. What makes something a “trait object”?
  6. Is it possible to use `impl Trait` as a function’s return type in a trait definition?
  7. How do I return an instance of a trait from a method?
  8. I implemented a trait for another trait but cannot call methods from both traits
  9. Why would I implement methods on a trait instead of as part of the trait?
  10. How does the mechanism behind the creation of boxed traits work?
  11. Trait implementation for both a trait object and for direct implementors of the trait
  12. Why is the `Sized` bound necessary in this trait?
  13. How can I implement Rust’s Copy trait?
  14. Is there any trait that specifies numeric functionality?
  15. Understanding Traits and Object Safety
  16. How do I pass a closure through raw pointers as an argument to a C function?
  17. Can’t implement a trait I don’t own for all types that implement a trait I do own
  18. Rust equivalent to Swift’s extension methods to a protocol?
  19. Cannot use moved BufReader after for loop with bufreader.lines()
  20. Do I have to implement a trait twice when implementing it for both reference and non-reference types?
  21. The compiler suggests I add a ‘static lifetime because the parameter type may not live long enough, but I don’t think that’s what I want
  22. When should I implement std::convert::From vs std::convert::Into?
  23. How can I call a mutating method while holding a reference to self?
  24. “parameter `’a` is never used” error when ‘a is used in type parameter bound
  25. Borrowing references to attributes in a struct
  26. How can I use a module from outside the src folder in a binary project, such as for integration tests or benchmarks?
  27. How can I modify self in a closure called from a member function?
  28. How can I find a subsequence in a &[u8] slice?
  29. Can traits be used on enum types?
  30. How do I create a HashMap with type erased keys?

Leave a Comment