Summary of efficient inheritance RFCs


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?


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?


@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. :slight_smile:


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:, and of course any future language changes will go through the RFC process and probably be posted on discuss too.


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.


What’s the state in 2018?

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


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).



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.