Proposal: Struct fields in concert with anonymous fields

[orenbenkiki]

Following http://smallcultfollowing.com/babysteps/blog/2013/10/24/single-inheritance/ and the thread at https://mail.mozilla.org/pipermail/rust-dev/2013-November/006465.html and referring to #9728

This proposal is in line with the single inheritance proposal, but puts it in context of anonymous fields. The key idea is separation of concerns: anonymous fields are used for inheriting implementation of "virtual functions", while "struct traits" are used for inheriting data members.

Neither the anonymous fields not the single inheritance proposals, when taken on their own, allow solving the full problem, since it is actually two (related) problems. This proposal puts them both together in a way that allows the programmer to express whatever best fits his problem - shared data members, shared methods, or both.

The proposal is as follows. Assume some form of anonymous fields support, that is, allowing:

pub struct FooS { foo: int }
impl  FooT for FooS { ... }
pub struct BarS { FooS; bar: int; BazS; ... }
impl FooT for BarS {} // Inherits trait implementation, possibly w/ overrided

With the expected semantics (allowing access to FooT trait methods via either ~FooS or ~BarS, at the cost of a virtual function call, e.g. along the lines of #9728).

We then add a new concept, "struct traits". Every struct is also automatically a trait. Any type implementing the trait has the matching struct as an anonymous member at offset 0 - that is, for any type implementing the trait, we can access all the struct data members at the same (known at compile time) offsets they exist at the original struct.

We provide the single-inheritance syntax for implementing struct traits. That is, the above code could be written as:

pub struct FooS { foo: int }
impl  FooT for FooS { ... }
pub struct BarS : FooS { bar: int; BazS; ... } // Single inheritance
impl FooT for BarS {} // Inherits trait implementation, possibly w/ overrided

The semantics of struct BarS : FooS are (1) behave as if the struct starts with a FooS anonymous member; (2) make the BarS type implement the FooS struct trait. That is, it would be possible to write:

fn useFoo<T: FooS + FooT>(t: ~T) {
    t.foo; // Simple data access at compile-time-known offset.
    t.method(); // Virtual function call using the FooT trait.
}
...
useFoo(~FooS { foo: 0 });
useFoo(~BarS { FooS { foo: 1 }, bar: 2 });
... 

Note that we maintain the seperation of concerns. Single inheritance does not imply implementing any trait other than the base struct trait. Normal (virtual?) traits are treated exactly as they are treated for normal anonymous members; they require an impl; etc.

Fast access to common data members is done via struct traits and single inheritance; restriction to single inheritance is understandable since it is an inherent requirement for zero-cost data member access (since a struct has only one prefix).

Invocation of "virtual methods" is done via traits as today. Anonymous fields allow us to inherit implementation if this is desired (or defining completely new implementation if we want). Invoking trait methods always incurs the extra cost of a virtual function call; this includes the cost of carrying a run-time-known offset for accessing the data members required by the inherited implementation. In this case, as usual for traits, it is possible for a struct to inherit and implement any number of traits, by using several anonymous members.

I propose this extension to the single inheritance proposal (or, if you look at it from the other direction, to the anonymous fields proposal) provides the best of both worlds, without having to restrict ourselves to single implementation inheritance (that is, give up mixins), and without having to give up the fast access to base data members (that is, give up on performance for a very common case).

[reem]

Triage: this would need to become a proper RFC to move forward, but l also think that this is probably subsumed by many of the later RFCs on single inheritance.

[steveklabnik]

Triage: yes, this would need to go through the RFC process. Since this is very similar to those issues, I'm just going to close, rather than move this, but feel free to write up a proposal if you'd like to persue it 😄