Am I using inheritance, borrowed pointers, and explicit lifetime annotations correctly? - memory-management

Question

I'm learning Rust, coming from an almost exclusively garbage collected background. So I want to make sure I'm getting off on the right foot as I write my first program.
The tutorial on the Rust site said I should be dubious of using pointers that aren't &. With that in mind, here's what I ended up with in my little class hierarchy (names changed to protect innocent). The gist is, I have two different entities, let's say Derived1 and Derived2, which share some behavior and structure. I put the common data into a Foo struct and common behavior into a Fooish trait:
struct Foo<'a> {
name: &'a str,
an_array: &'a [AnEnumType],
/* etc. */
}
struct Derived1<'a> {
foo: &'a Foo<'a>,
other_stuff: &'a str,
}
struct Derived2<'a> {
foo: &'a Foo<'a>,
/* etc. */
}
trait Fooish<'a> {
fn new(foo: &'a Foo<'a>) -> Self;
/* etc. */
}
impl<'a> Fooish<'a> for Derived1<'a> {
fn new(foo: &'a Foo<'a>) -> Derived1<'a> {
Derived1 { foo: foo, other_stuff: "bar" }
}
/* etc. */
}
/* and so forth for Derived2 */
My questions:
Am I "doing inheritance in Rust" more-or-less idiomatically?
Is it correct to use & pointers as struct fields here? (such as for string data, and array fields whose sizes vary from instance to instance? What about for Foo in Derived?)
If the answer to #2 is 'yes', then I need explicit lifetime annotations, right?
Is it common to have so many lifetime annotations everywhere as in my example?
Thanks!

Answer 1

I'd say that this is not idiomatic at all, but sometimes there are tasks which require stepping away from idiomatic approaches, it is just not clear if this is really such a case.
I'd suggest you to refrain from using ideas from OO languages which operate in terms of classes and inheritance - they won't work correctly in Rust. Instead you should think of your data in terms of ownership: ask yourself a question, should the given struct own the data? In other words, does the data belong to the struct naturally or it can be used independently somewhere?
If you apply this reasoning to your structures:
struct Foo<'a> {
name: &'a str,
an_array: &'a [AnEnumType],
/* etc. */
}
struct Derived1<'a> {
foo: &'a Foo<'a>,
other_stuff: &'a str,
}
struct Derived2<'a> {
foo: &'a Foo<'a>,
/* etc. */
}
you would see that it doesn't really make sense to encode inheritance using references. If Derived1 has a reference to Foo, then it is implied that this Foo is created somewhere else, and Derived1 is only borrowing it for a while. While this may be something you really want, this is not how inheritance works: inherited structures/classes usually contain their "parent" contents inside them; in other words, they own their parent data, so this will be more appropriate structure:
struct Foo<'a> {
name: &'a str,
an_array: &'a [AnEnumType],
/* etc. */
}
struct Derived1<'a> {
foo: Foo<'a>
other_stuff: &'a str,
}
struct Derived2<'a> {
foo: Foo<'a>,
/* etc. */
}
Note that Derived* structures now include Foo into them.
As for strings and arrays (string slices and array slices in fact), then yes, if you want to hold them in structures you do have to use lifetime annotations. However, it does not happen that often, and, again, designing structures based on ownership usually helps to decide whether this should be a slice or a dynamically allocated String or Vec. There is a nice tutorial on strings, which explains, among everything else, when you need to use owned strings and when you need slices. Same reasoning applies to &[T]/Vec<T>. In short, if your struct owns the string/array, you have to use String/Vec. Otherwise, consider using slices.