Try   HackMD

Types team, a charter and initial roadmap

Mission / charter

The "types team" owns the design, implementation, and maintenance of the Rust type system (but not the user-facing syntax of Rust). This includes the Rust type checker, trait system, borrow checker, and the operational semantics of MIR (and eventually Rust itself). As part of the operational semantics, the team is also ultimately responsible for deciding what is "undefined behavior".

Motivation

The types team is meant to build a base of maintainers for the formal side of Rust, both design and implementation. This has traditionally been an area with a very low "bus factor", both in terms of the compiler (few maintainers to the code) and the language design (few people who fully understand the entire space). Focusing a team on just Rust's "type system" will allow us to do targeted outreach and to help people to learn the background that is needed to contribute here.

Like the compiler team, the team's plays a "supportive" role. Its goal is to ensure both that Rust's type system has an efficient and correct implementation and that the type system (design and implementation) is able to scale to new demands and requirements. At this moment, Rust is suffering from a general paralysis in which new features (implied bounds, const generics, specialization, etc) are stalled for long periods of time due to a combination of an inflexible implementation, a lack of maintainers, and a general difficulty in reasoning about their interactions.

Parent teams

The types team is a child of the compiler and language teams. It interacts with those teams in the following ways:

  • Compiler, rust-analyzer, and others:
    • Assessing and implementing fixes for soundness bugs that have to do with the type system
    • Maintaining a shared library that implements the Rust type/trait system
  • Lang team:
    • Maintaining the Rust model and extending it to model new proposals that interact with the type checker
    • Assisting with the design of language extensions that extends the core Rust type system capabilities
      • The "user-facing" element of these changes is T-lang, but the underlying semantical modes is T-types.
    • Advising on how to fix soundness bugs that will require language changes

Examples to illustrate the scope of the types team

Here are some examples to illustrate how the types team will interact.

Evaluating the implication of equality constraints or negative trait bounds

The original RFC for where clauses included equality constraints like where T == U (tracked by #20041); similarly, people have regularly considered including the option to have "negated" where clauses like where T: !Debug. Both of these features, if led to their full generality, turn out to make the implementation of Rust's trait solver significantly more complicated. Therefore, the types team is within its rights to veto these features or to suggest appropriate modifications to how they work and what they mean. On the other hand, it is up to the lang team to decide the syntax of those where clauses and whether they'd be a useful addition to Rust (presuming they had a semantics the types team was happy with). The types team cannot add a feature to Rust all by itself, but it can either remove one (because it is not feasible to implement) or tweak its formal semantics (to ensure it is sound, feasible etc). In this respect, it is just like the compiler team.

Bug in the type checker

When a soundness bug is found in Rust's type system, the compiler team can contact the types team to request the bug be triaged and to prepare a fix. The types team owns that code and hence is ultimately responsible for reviewing changes to the relevant code.

Github Projects

Although this set may change over time, the types team maintains the following projects:

The team is also responsible for those portions of rust-lang/rust that implement the type system (jointly, with the compiler team, since those portions are not cleanly separable).

Active initiatives

The currently active initiatives of the trait team are as follows:

Stalled initiatives

Other initiatives that are somewhat stalled but looking to be rejuvenated:

  • Polonius: re-implementing the Rust borrow checker in a more flexible, alias-analysis-like fashion
  • Chalk-ty: implementing a shared library to represent types in rustc, chalk, rust-analyzer, and beyond
  • Chalk: implementing a library
  • Unsafe code guidelines: deciding what behavior is legal or not legal for unsafe code

Team membership

Membership in the team is awarded on the basis of experience working on the implementation, source, or design of an active initiative. Membership is kept up to date; if you are inactive for >6 months, we may move you to the alumni team.

To become a member you typically have to (a) contribute consistently over a period of multiple months and (b) lead at least one "deep dive" (see below). The second point may be waived.

Leads

The current team leads are Nicholas Matsakis and Jack Huey. Leads are responsible for:

  • Leading and scheduling team meetings
  • Selecting the deep dive meetings
  • Making decisions regarding team membership
  • General "buck stops here"-type decisions

Leads typically serve for 6 months to 1 year, at which point we will consider whether to rotate.

Organization, how the team runs

The main work of the team is done as part of active initiatives. There is no team-wide "triage" meeting. Instead, each initiative operates independently and are driven primarily by their individual owners. If it is useful to them, they may choose to have their own triage meetings or other forms of organization.

The team does have a weekly slot reserved for team-wide meetings. Like the compiler/lang teams, that slot is used for two purposes:

  • Planning meeting (typically first week of the month)
  • Deep dive meetings (scheduled during the planning meeting)

Planning meeting (starts April)

We review the overall roadmap for each active initiative and set some kind of goals.

Each initiative is responsible for preparing a short (1-2 paragraph) document in the leadup to the planning meeting with the following structure:

  • What was the plan at the start of the month (list of goals)?
  • What happened? (brief narrative)
  • What is the plan for this month (list of goals)?

The meeting begins by reading these documents and asking questions. The goal is to adjust the goals for each initiative so that they are realistic; we should be helping each other to calibrate and set expectations. The final document is then published as a blog post.

Startup period: During March, nikomatsakis will meet with the various initiatives to draw up the initial documents for the first planning meeting.

Deep dive meeting (starts end of March)

A "deep dive" meeting takes the form of reviewing a write-up, a PR, or otherwise diving into some topic together. They are expected to last 90 minutes but perhaps longer. Deep dive meetings for a given month are scheduled during the planning meeting.

Frequently asked questions

Why a team and not a working group? What is the difference between those anyway?

A team focuses on maintaining and extending some aspect of Rust (e.g., compiler, language, stdlib) so that it works well for all Rust users. As the owners of that area, they have final decision making power. Teams are (relatively) permanent, as they tend to an area of functionality and need to do maintenance, bug fixes, and the like. (It's possible of course to decomission a team, either because there is no one to do the work, because the work is now being done by another team, or because the product the team was maintaining has gone away.)

A working group focuses on improving Rust for a particular purpose or target domain (e.g., async, CLI, but also more abstract purposes like error handling). Typically, they do that work by preparing recommendations (e.g., in the form of RFCs) that are then adopted by teams (though in some cases, working groups own and maintain repositories as well, which they have jurisdiction over). Working groups are temporary – at some point, the domain is served "well enough" and the action moves out to the ecosystem at large. (This may, however, take a long time.)

For completeness, an initiative is a specific project undertaken by some team(s) or working group(s). Initiatives lie at the intersection of teams and working groups, where the team(s) are tasks with ensuring that the initiative is a good, general purpose addition to Rust, and the working groups are tasked with making sure it will satisfy their specific needs.

The amount of organization involved in a team or working group is another factor. Both of them should have a lead and some amount of coordination, though that coordination doesn't have to come in the form of weekly meetings. For things that don't meet that level of organization, we probably want another term, such as "notification group".

NB: We have traditionally used these terms in a variety of ways, not all of which fit the above definition. For example, the compiler team's LLVM working group is, by these definitions, a subteam (or perhaps notification group, as the LLVM subteam doesn't have a lead or agenda to my knowledge). I would argue that we should change wg-llvm to match these definitions. –nikomatsakis

Wait, it has TWO parent teams?? Can you do that???

Why the heck not! The team really has two aspects to its character, and so I think it belongs in both.

OK, so it should be a team, but why the "types" team?

We went back and forth on the name and decided that the "types" (or "type system", in full) hit the "sweet spot" in terms of being short, suggestive, and memorable. The "type system" for Rust in general encompasses all of its static checking, so the name is appropriate in that regard; the team is also responsible for defining Rust's operational semantics (what effect Rust code has when it executes), which is not part of the type system, but that's ok.

Other names considered:

  • the traits team
  • the semantics team
  • the formality team

What do you expect the planning meetings to do?

The role of the planning meeting is to…

  • Encourage initiatives to set goals and track their progress.
  • Give us a simple way to advertise the work that is getting done.
  • Help the various initiatives stay in touch with each other at a high-level.

What do you expect the deep dive meetings to do?

Whereas the planning meetings aim to keep people in touch at a high-level, the deep dive meetings…

  • Give an opportunity to understand a single topic in depth
  • Give an opportunity for an initiative to ask for help, with enough time to get the requisite context
  • The act of preparing for the meeting often helps on its own
  • Because they are centered around documents that can be published, gives a record of important material

What are the steps to put this plan into action?

  • Switch compiler/lang check-ins to be for initiatives, not traits overall
  • Start the planning / deep-dive cycle – done! Meetings are Friday morning at 9am US Eastern Time.
  • Author a T-lang/T-compiler RFC from this document
Last changed by 
 
Niko Matsakis
0
1389
Published on HackMD