Summary of efficient inheritance RFCs

[tomaka]

This may sound weird, but I like the fact that inheritance is difficult/“ugly” to use, because it makes people less likely to choose to use it rather than generics and traits.

[arcto]

It does sound weird. Naturally, a language design that makes code ugly or difficult to write – and therefore to read – is the worst possible language design. It’s a failed design. Good design allows you to express your ideas using a small subset of orthogonal constructs without ambiguity or redundancy.

[tomaka]

We already have a good design, they are traits. Making inheritance difficult to use in Rust shows that we don’t want you to use it except if you are certain that there are no other solution.

[CloudiDust]

I worried about this too. But this problem doesn’t quite exist when inheritance is based on traits. C++ has this problem because its template/concept system is completely bolted onto the object system. But Rust can unify all of them into the enhanced traits, of which RFC PR 250 is the most seamless IMHO. RFC PR 223 takes more of a “building blocks” approach and do not directly enhance (normal) traits (the author is planning to adopt parts of PR 250, it seems).

I believe the good bits of several RFCs can be combined to form a satisfying solution which is flexible and hard to misuse.

[arcto]

I have good faith in the Rust community and this discussion. A good solution will be found that is pleasant, performant, hopefully derives advantage from the trait system.

[rpjohnst]

I have yet another RFC: Layout Inheritance

It’s based on an idea from this issue that never really made it into an RFC on its own, which is one of the simplest versions that’s still nice and orthogonal.

[nrc]

I have made quite a few changes to the RFC based around enhancing enums and adding implementation inheritance. I would like to tell the story of this RFC in parts (I’ve done this in the RFC summary in more depth):

*make Rust data structures more powerful, more orthogonal, and more unified. This includes data inheritance which, in keeping with the data/behaviour separation in Rust is totally separate from trait inheritance/implementation.

*Add behaviour inheritance which follows data inheritance when implementing a specific trait. I hope this feels natural as a way to share behaviour between related data types.

*Offer optimisations for speed and space using the closed and unsized annotations.

I hope that this addressed the two big (concrete) criticisms of earlier proposals about the near-unification of enums and structs, and the inheritance in trait-less impls.

[tomjakubowski]

Can RFC PR 250 (kimundi and eddyb’s proposal) be linked into the OP with the others?

[eddyb]

You’re not supposed to use it unless you really know what you’re doing, and then it’s an opt-in layout optimization that sacrifices flexibility for some domain-specific gains. It’s not a kind of “inheritance”, and I would compare its “user friendliness” to #[repr(C, packed)].

[eddyb]

It’s not intentionally ugly or obtuse, but rather verbose: clearly stating your intent to change the representation of trait objects of a given trait to “thin pointers”, forcing single inheritance chains in the trait hierarchy (which does not limit it to single inheritance relations everywhere, btw). The mechanism could be extended in the future to allow C++, COM or Objective-C interop. The Vtable primitives seem complicated because they use type safety to avoid requiring unsafe code.

[DanielFath]

You still need to ‘sell’ it to Gecko people. If it’s that verbose, I fear it will turn them off.

[eddyb]

I don’t need to “sell it” to any “Gecko people”, Servo needs optimizations not C++ syntax or semantics, and the fact that it is entirely safe is a big bonus. And they can always use macros to make their specific trait hierarchy details implicit. Which makes me wonder, how much of that is generated from WebIDL?

[DanielFath]

I disagree. On some level if Rust doesn’t convince enough people to switch it will be just an interesting research language. Its main audience will probably come from a C-like language.

Again I am ok with slightly more verbose syntax. This just feels syntaxically inferior to current enum/struct syntax AND C++ syntax. It contains huge amount of boiler plate. Its not so much a speed bump as a pot hole.

If enum inheritance has worse performance than this inheritance then this proposal will push people towards a performance inferior alternative i.e. enums inheritance. If this proposal has same or worse performance compared to enum/struct why even make it? Why not just improve upon it, if its that necessary?

[CloudiDust]

@DanielFath, macros can help here, and one that emulates C++ style classes and does optimizations, with little syntax overhead, is actually provided in the RFC’s comments. I don’t think people will be turned away from Rust because println! is a macro.

This RFC chooses “flexibility by default”, and it is not “intentionally ugly”, which I personally like.

With #223 and friends closed/going to be closed now, #250 is the most flexible alternative, while other open alternatives provide more lightweight syntax by default but are not as flexible.

And for me, anything that looks like “extending structs/enums” just feels wrong, but this is totally subjective.

[nrc]

We’ve had a couple of meetings about this (minutes are here and here ), we discussed the proposals and the goals with this work. We basically decided to punt on the question for another couple of months so we can concentrate on higher priority/more urgent things, and so we can discuss when we’re mostly all going to be in the same room.

Thanks for all the input, both proposals and discussions! We really appreciate it. In particular, I’d like to point out that all the ideas that we’re considering originated from the community in one way or another.

You can follow further developments in the tracking issue: https://github.com/rust-lang/rfcs/issues/349, and of course any future language changes will go through the RFC process and probably be posted on discuss too.

[bjz]

It would be really nice if proposals could consider interactions with other planned type system features. You are probably already considering this, but it would be helpful to make it explicit. @zwarich has already done a good job clearing up some of my concerns, but not everyone reads reddit.

[sighoya]

What’s the state in 2018?

Couldn’t we agree to any “inheritance” proposal?

[nrc]

The favourite idea in the end has been a combination of leveraging specialisation and adding fields to traits. However, that is blocked on specialisation which is not yet stable and the feature as a whole is no longer considered high priority, so it won’t be in the 2018 edition (it is definitely still desirable, we just have a lot of higher priority things happening).

[sighoya]

@nrc

Specialization and fields in traits are a good thing, but afaics specialization doesn’t cover hierarchic runtime dispatching only the static variant of it which is, however, on default a very good decision.

However in certain cases a runtime variant of it is useful and would provide the last feature together with upcoming generic variadics and constant generics to finally reship C++ into grave.

[nrc]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.