Efficient code reuse

Motivation

Data structures which closely fit a single inheritance model can be very efficiently implemented in C++. Where high performance (both space and time) is crucial there is distinct disadvantage in using Rust for programs which widely use such data structures. A pressing example is the DOM in Servo. For a small example in C++, see https://gist.github.com/jdm/9900569. We require some solution which satisfies the following requirements:

• cheap field access from internal methods;
• cheap dynamic dispatch of methods;
• cheap downcasting;
• thin pointers;
• sharing of fields and methods between definitions;
• safe, i.e., doesn't require a bunch of transmutes or other unsafe code to be usable;
• syntactically lightweight or implicit upcasting;
• calling functions through smartpointers, e.g. fn foo(JSRef<T>, ...);
• static dispatch of methods.

Status

There has been discussion of potential solutions on discuss (http://discuss.rust-lang.org/t/summary-of-efficient-inheritance-rfcs/494) and in several meetings (minutes and minutes).

We clarified the requirements listed above (see the minutes for details) and established that an ergonomic solution is required. That is, we explicitly don't want to discourage programmers from using this feature by having an unfriendly syntax. We also summarised and evaluated the various proposals (again, see the minutes for details). We feel that no proposal 'as is' is totally satisfactory and that there is a bunch of work to do to get a good solution. We established a timeline (see below) for design and implementation. We would like to reserve a few keywords to reduce the backwards compatibility hazard (#342).

Plan

In December the Rust and Servo teams will all be in one place and we intend to make decisions on how to provide an efficient code reuse solution and plan the implementation in detail. We'll take into account the discussions on the various RFC and discuss comment threads and of course all the community members who attend the Rust weekly meetings will be invited. We will take and publish minutes. This will lead to a new RFC. We expect implementation work to start post-1.0. If we identify backwards compatibility hazards, then we'll aim to address these before the 1.0 RC.

RFC PRs

There have been numerous RFC PRs for different solutions to this problem. All of these have had useful and interesting parts and earlier RFCs have been heavily cannibalised by later ones. We believe that RFC PRs #245 and #250 are the most relevant and the eventual solution will come from these PRs and/or any ideas that emerge in the future. For a summary of some of the proposals and some discussion, see this discuss thread.

• https://github.com/rust-lang/rfcs/pull/254

Start with the requirements in this issue, then read the linked discuss thread, the 2014-09-23 and 2014-09-30 meeting minutes, and RFC PRs #245, #250, and #254. The work is complete only after the teams agree on an ergonomic efficient code-reuse design and produce the planned RFC; implementation was expected after 1.0.