Trait based inheritance

[gereeter]

This is largely based upon #9 and #91, but fleshed out to make an actual inheritance proposal.

[pczarn]

s/acheive/achieve/

[nrc]

There is already an attribute (crepr or something similar) which forces the fields in a struct to be stored in the order they are specified. Would that be enough or do you still need first_field?

[gereeter]

That would be enough, but it would also be overkill - it would still be nice for the compiler to be free to reorder the rest of the fields.

[rpjohnst]

👍 This is how Rust inheritance should work. This level of flexibility could even allow for bindings with other object models- various C++ layouts (potentially even with multiple inheritance), COM, etc.

[zwarich]

How will safe downcasting work with lifetime parameters? In the example, Node has no lifetime parameter but TextNode and ElementNode do. As described, it seems that downcasting with transmute will just introduce a new lifetime parameter out of thin air, which isn't correct.

For downcasting to be safe it seems that all members of a class hierarchy need to have identical lifetime parameters, the copy of a parent class in a child class needs to be instantiated with the same parameters as the child, and the downcasting operation needs to respect these parameters.

[gereeter]

I believe the issue with these lifetimes that seem to pop out of thin air was fixed by #192. Basically, because TextNode<'a> only implements Extend<NodeData>, not Cast<NodeData>, there is no way to convert from a TextNode<'a> to NodeData in an owned context. The are only two ways to get NodeData from a TextNode<'a>. First, when stored behind a reference, the two representations can be switched. However, this is perfectly safe, as the text must outlive the reference. Second, the TextNode<'a> could be converted to a trait object of Node. Due to #192, this must also be safe, as the trait object must be annotated with an explicit lifetime bound.

I'll try to update the examples to make this more clear.

[CloudiDust]

+1 to this proposal.

As pointed out in the proposal, the traits here can be the low level building blocks, providing maximum flexibility, while commonly used inheritance patterns can be codified in macros. (Sort of like Ecmascript 6's class syntax vs the underlying prototype-based OO which is both more flexiable and more "alien".)

It will make people think twice before using inheritance, simply because the relative verbosity and the "ugliness" of macro invocations compared to dedicated syntax.

I consider this a plus and don't think we need to artifically limit inheritance in any other way. (IMHO, #142 needs limitations partly because the syntax there is too lightweight and pretty. That can be both an advantage and a disadvantage.)

[bluss]

Cast is almost the wrong name for the trait, because casting in both Rust and C is a conversion preserving the value, not something like a blind transmute.

[zwarich]

@gereeter That approach doesn't work with multiple lifetime parameters, does it? Also, what about non-lifetime type parameters?

[gereeter]

@zwarich The same approach should work fine for multiple lifetime parameters: in the trait object case, the object would have to have all the lifetime bounds, and in the reference case, any reference would have to outlive all lifetimes involved.

For non-lifetime type parameters, the parameter would be part of the RTTI.

[nrc]

For easy comparison with the other proposals for handling DOM-data structures, could you show how https://gist.github.com/jdm/9900569 would look encoded with this proposal please?

[jdm]

s/Entend/Extend/

[alexcrichton]

@gereeter, could you add an example of how https://gist.github.com/jdm/9900569 might be encoded with this RFC? The example at the end looks similar, but not quite the same.

[ben0x539]

Is this cleverly crossborrowing node into a shared reference? (Probably should be Some(...), not Ok(...))

[nielsle]

Bikeshedding. Could the following syntax work? Here @Coerce should "magically" ensure that the layout is fixed.

@coerce(Node)
struct MyNode { node: Node,  .... }

Perhaps this could open the door for future self inspection syntax..

@coerce([f32,.. 3])
struct MyVec { x1: f32, x2:f32, x3:f32 }

let xs = MyVec {x1:0, x2:0, x3:0}
for x in cast(xs).iter() { .....}

[glaebhoerl]

Is this correct? It seems like it should either be T: Cast<T2> rather than Extend or impl Extend rather than Cast. (T: Extend<T2> does not imply that Bundle<U2, T2> and Bundle<U, T> have the same representation, which is what impl Cast is stating.)

[glaebhoerl]

This is essentially the same thing as the existing Any trait¹.

¹ Except that as the current Any is implemented, it is known to be impled by all types T: 'static, which is obviously wrong.

[huonw]

obviously

It's not to me, could you explain in a little more detail?

[glaebhoerl]

fn evil_id<T: 'static>(mut arg: T) -> T {
    if let Some(an_int) = (&mut arg as &mut Any).downcast_mut() {
        *an_int = 666i;
    }
    arg
}

I shouldn't be able to do this. I should have to specify T: Any. (I should be infer from the absence of an Any bound that the function won't do something like this. 'static should only mean 'static.)

[reem]

'static should mean 'static and impl<T: 'static> Trait for T should also mean that you always get Trait when you have 'static - I see no reason why this is at all unreasonable.

[glaebhoerl]

I agree with what you wrote, but I was never implying otherwise.

The unreasonable part is having impl<T: 'static> Any for T in particular. We should have compiler-generated impls for each type individually, but not a blanket impl for all types. The Any bound should be satisfiable by any concrete type, but not by abstract type parameters except if one explicitly writes T: Any. (As this RFC also states.)

[reem]

I'm still unsure why this actually needed.

Wouldn't

impl <T: 'static> Typed for T {
   static TYPE_ID: TypeId::of::<Self>()
}

do the same job as an impl for all types? I'm not clear on why it's important that I have to write specifically T: Typed.

[glaebhoerl]

So that contracts are explicit and type signatures actually mean something. If we allow dynamically casting any abstract type to any other type, then a function requiring T: 'static could do just about literally anything (see above evil_id). It should be possible to know that a generic function only manipulates / makes use of its type parameters in accordance with the trait bounds which it specifies. I don't know how else to rephrase this to make it clear why this is desirable.

[reem]

Does this mean you are proposing we should remove Any?

[glaebhoerl]

No, I just think it should be implemented differently. I would prefer (as, again, this RFC we're commenting also proposes) to remove the blanket impl<T: 'static> Any for T impl (it's actually AnyPrivate but that's unimportant), and instead, whenever you write:

struct Foo;

the compiler automatically derives:

impl Any for Foo { ... }

[glaebhoerl]

This is essentially saying that Typed would have an associated static rather than associated fns:

trait Typed {
    static TYPE_ID: TypeId;
}

Associated statics are part of the proposal for associated items by @aturon.

[glaebhoerl]

Unless I'm missing something, I believe all of these also need to require A: Typed.

Edit: Also, is the Cast requirement buying us anything here? As far as I can tell it's enforcing that the casts be strictly _down_casts, but I don't see why we couldn't or shouldn't allow dynamically-checked casts between arbitrary pairs of types. (The _down_cast restriction can be enforced by clients further out by requiring Cast themselves, if that's what they want to do.)

[gereeter]

The Cast requirement is there to ensure that it is even possible for the downcast to succeed - since the actually transformation is done via a transmute, the only way it could possibly be safe is if there is a Cast relationship. Technically, it isn't needed, but there isn't any reason not to throw out downcasts that will never succeed.

I believe you are correct about A: Typed.

[glaebhoerl]

I think this variation would be preferable (we could also use super as a modifier). Generally attributes are at least supposed to be "only metadata"; if it has an effect on which things typecheck, then it's probably better for it to be a first-class language construct.

[glaebhoerl]

My preferences here would be:

#[first_field]   -> super
mem::transmute() -> mem::force_transmute()
Cast/Coercible   -> Transmute
cast()/coerce()  -> transmute()
HasPrefix/Extend -> Extends
Any/Typed        -> Dynamic

Rationale:

• (#[first_field] vs. super: See above.)
• The word Rust uses for no-op bit-level reinterpretations is "transmute". So it makes sense to use this word here, because that's what we're doing.¹ The safety of the plain transmute() function would be assured by the presence of Transmute impls, while the current unrestricted, unsafe version would be renamed to e.g. force_transmute().
• Using the word "extend" here is a great idea! I think Sub: Extends<Super> reads better.
• It makes tons of sense for the trait used to obtain dynamic typing to be called Dynamic. And e.g. Box<Dynamic> reads very well.

¹ The earlier name Coercible has already mislead some people into thinking that it has something to do with "coercions", by which Rust means "automatic compiler-inserted non-representation-preserving conversions", when in fact it doesn't.

[vadimcn]

Why super and not struct Child: Parent? The latter would rhyme better with trait inheritance, IMHO.

[huonw]

If it were super field_name: Parent (I assume this is what @glaebhoerl meant?) then it's easy to explicitly access things using the parent (this isn't necessary a good thing in all circumstances), and you don't get any 'surprise'/implicit fields being introduced.

[glaebhoerl]

I assume this is what @glaebhoerl meant

Yes. Basically I like this option because it's the most minimal one (apart from an attribute, which I think is too minimal) which accomplishes what we need.

We could have something like struct Child: Parent, but that has other implications which are out of scope with respect to our goals here. If it's just e.g. sugar for lifting the fields of Parent directly into Child without implying subtyping voodoo, then I wouldn't necessarily mind having it, but I think it would be best discussed as a separate proposal.

[vadimcn]

@huonw: I would assume you'd just access them via self, same like parent methods under trait inheritance. I doubt that anyone who'd programmed in the last 20 years would be surprised. Besides, if Parent fields have to be accessed via super, what happens with deeper hierarchies? self.super.super.super.super.field ?

@glaebhoerl, can you please give an example of other implications of strict Child: Parent?

[glaebhoerl]

Well... I already did. It would also force us to think about e.g. how to handle name shadowing of fields, which is a complication that doesn't currently exist. And the struct Child: Parent syntax would lead people to believe it also enables things like passing &Child where &Parent is expected, which is a whole other can of worms.

The point is only that none of this is necessary for the purposes of this RFC. All that we need here is for Child: Extend<Parent> to be satisfied, and all that we need for that is for the physical layout in memory of the Child struct to begin with Parent, and all that we need for that is to be able to specify which field comes first in the struct. We don't otherwise need to change how existing structs already work in any other way.

But this is really a minor detail of the design and I don't care that strongly about it, so I'm not going to argue it further.

[reem]

How about just a straight rename of #[first_field] to #[super] with no additional semantics?

[glaebhoerl]

See other comment.

[vadimcn]

Well... I already did. It would also force us to think about e.g. how to handle name shadowing of fields, which is a complication that doesn't currently exist.

Don't we already have this problem with traits? And it must have been resolved somehow, so we could do the same here.

And the struct Child: Parent syntax would lead people to believe it also enables things like passing &Child where &Parent is expected, which is a whole other can of worms.

This RFC already allows for that, though requires an explicit cast. Or am I reading it wrong? Implicit casts would be a backwards-compatible addition, so they could be done later.

BTW, I totally agree with attributes being "too optional" to be part of a major language feature like this.

[huonw]

An array of pointers to objects, I assume?

[gereeter]

Probably - I could image a situation where substructs are used to add methods and not data and you could store everything by value, but pointers will be the common case. Also, note that it doesn't have to be just a pointer to an "object" as would be enforced by other proposals - there could be more data associated with the pointer, such as if a choice is made to use fat pointers.

[huonw]

Do we actually want -128i8 to magically turn into 128u8? Also, would something like Extend<u8> for u16 be sensible (it seems nearly as semantically sensible as u8 <-> i8, modulo endianness)?

[glaebhoerl]

It's not really "magical" if you invoke cast() (or transmute(), whatever we name it) explicitly. This kind of thing is the whole point.

[huonw]

Well, the cast could be nested deep inside some other data structure (e.g. HashMap<..., Vec<(uint, u8)>>) so it may not be immediately obvious what's happening, but yes, I take your point.

[gereeter]

It may not be immediately obvious what is happening, but the ability to convert HashMap<..., Vec<uint, u8>> to HashMap<..., Vec<int, i8>> could in fact be very helpful.

[huonw]

What is the n here?

[gereeter]

Number of classes in the inheritance chain between the actual class and the class you want to cast to, or total number of classes in the inheritance chain if the downcast fails, I think. I'm not certain about this, but I remember reading that some implementations of RTTI, to support open inheritance, use a linked list of classes that has to be linearly scanned to find if the target class is present.

[nwin]

How about renaming #[first_field] to #[parent]? The RFC seems to be conceptional close to Self where parent objects are mostly saved in a slot called parent. So it would just seem natural to mark the parent object with #[parent].

[vadimcn]

... or VTable ?

[brson]

The consensus among the core team is that while this is an orthogonal set of abstractions, in actual use they do not present an ergonomic user experience.

Discussion