Right. Idiomatic Rust prefers composition over inheritance.

Every language in the universe prefers composition over inheritance =P

Not very true.

Some languages prefer inheritance to express is-a relationships and composition to express has-a relationships. Some languages try to shoe horn is-a into being equivalent to has-a, but they usually have trouble expressing non-structural subtyping.

I find that when refactoring code, I often redefine is-a to has-a anyway.

is-a vehicle --> has 4 wheels

Runtime error: Motorcycle lacks 4 wheels

The ones that don't blossom into interface factories which make factory adapters of abstract factories. (I'm looking at you, Java)

For the lack of a nail, throw new HorseshoeNailNotFoundException("no nails!");

For the lack of a horseshoe, EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();

(...)

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...

If that is the only use case I would rather want another solution to keep the language minimal. Just like the garbage collection was moved to a library.

Can't really do it. I tried. The type checker just plain has to know about inheritance for it to work and be safe.

The good news is that's an extremely constrained sort of inheritance, very unlike traditional OO in that it doesn't have base classes--it's just a special extension to the trait (typeclass) system that allows you to require that structs begin with a certain set of fields. In fact, I don't even call it inheritance these days--I prefer the name "structural constraints".

ooh, is this like record subtyping? Have you seen ermine https://github.com/ermine-language or Ur/web? http://www.impredicative.com/ur/

[edit, on #rust it was explained to me that its only for pointers to structs, but thats fine by me]

If anyone is interested, the proposal for Rust is detailed in http://smallcultfollowing.com/babysteps/blog/2013/10/24/sing...

I think this is a good idea. It seems similar to Go's embedding: http://golang.org/doc/effective_go.html#embedding

The difference is that the base struct can call methods on the derived struct, whereas this is not possible with that kind of struct embedding. This is important for some use cases (e.g. the DOM or the render tree).

I see.

Thanks for the answer, and I think I like your solution to the problem.

I think that the core team thought about this long and hard, but it was decided that there was no other solution. A virtual method call to look up some property shared by all the DOM nodes was just too expensive: a constant offset field look up is far far faster.