---
title: T-spec meeting 2024-05-16
tags: ["T-spec", "meeting", "minutes"]
date: 2024-05-30
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-05-30
url: https://hackmd.io/2ZYlaOI_SbC-3_gdm0a0Cw
---

## Attendees

Joel Marcey, carbotaniuman, Pierre-Emmanuel Patry, Connor Horman, Eric Huss, TC, Urgau, Sid A, pnkfelix, Pietro

## Regrets

Mara Bos

## Potential Agenda

* Announcing new t-spec team member
* Joel on leave for two weeks until 20 June
* Resolving Reference vs. FLS vs. from scratch debate (hopefully) once and for all
* MiniRust meeting update
* Core Library Fit

## New t-spec team member

TC has joined the t-spec team.

## Joel out for a while

Felix: Will someone take over Joel's role while he's out?

Joel: Meetings should continue.

## The Great Debate

Joel: Decision cannot be unanimous.

Joel: I do not have the experience/knowledge, we will hire someone. No name announced yet.

TC: Having recently joined the rustdoc team, I've been having a closer look at the Reference and the PRs to it. It's given me some further appreciation for this body of work and some further pause about trying to recreate it. It has over 110k words. It's been worked on for ten years by over 400 authors. It's been carefully maintained.

TC: If we were to adopt the Reference, my proposal is that we literally *adopt* it, wholesale, rather than forking it.

Felix: I too are wary of the "second system syndrome." There is a difference between adopting content and the structure/system (source content to the readable content) for a specification. If we aren't going to make the Reference look like a spec, then that is not great and maybe we should start with the FLS in that case.

TC: I agree that we can and should adapt the Reference, if we adopt it, to whatever layout and format we want.

Sid: Please explain what you mean by tooling?

Felix: Going from source content to the actual specification document that is readable.

Sid: We have been given a "gift" with a starting a point, either from the FLS or Reference. But has a gap analysis been done? But there is a huge opportunity here. When this first started, thought we were going to bang on something quickly and then iterate. There are stakeholders who want to see a specification and are using it to help with the groundswell of Rust support. We are 6 months behind it feels like.

Joel: Yes, we are at least 3-6 months behind.

Connor: False Benefit Fallacy - is the goal to get something done short-term or to reduce our work over time? Feels the reference is the former, but it is not written such that it will end up being a long-term specification.

Joel: Taking Connor's point even further, the from scratch topics that we came up may probably be the best long-term supported goal

TC: I spent some quality time reading the FLS. It's missing many things from the Reference that we should not lose, both in terms of depth and in terms of clarity of meaning. The Reference, e.g., gives examples to clarify ambiguous points, and it uses terminology more familiar to Rust. The FLS, by contrast, is very similar to the Ada spec and reuses much of its terminology. I can see how similarity to Ada is a benefit for certification, but it sacrifices other desirable items. (It's also, in terms of word count, only about 60% the size of the Reference.)

Joel: The FLS does fit some stated goals in the RFC, such as supporting safety-critical industry.

Pietro: We aren't solving the right problem right now. We need to solve the "who is doing the work" problem first because those people will be the ones actually having to deal with the chosen base of from scratch on a day-to-day basis. That said, the FLS *is* the Rust specification right now because the safety critical industry is using. Recommend starting from the FLS and do passes over it and find mistakes over passes.

Joel: Agrees with the resources comment Pietro made.

TC: What the people working on the spec will want to do is driven by what we as stakeholders want out of the spec, i.e. by what we define as acceptance criteria. If we say we want something useful for certification in safety-critical industries and we want that in 3 months, then clearly those people would start with the FLS. If we say we want something useful for iterating on the language, for developing shared terminology between contributors, and for helping people to understand the details of how the language works -- and that we want that in 3 months -- then those people would clearly start with the Reference. Our outcomes here will be driven by our goals in terms of audience, purpose, and timelines.

TC: Here's another proposal, which I've earlier discussed with some people. Let's call this the *dark horse* proposal:

- We adopt both the Reference and the FLS.
- We call the Reference either "the Rust Reference" (no-op) or the Rust Specification.
- We call the FLS the "Rust Safety-Critical Specification".
- We continue to ask only of contributors to update the Reference, and we continue to improve the Reference as we normally would (and, as resources permit, we make the Reference more spec-like in the ways we desire).
- Ferrous Systems promises that they'll keep the RSCS up to date (and, possibly, improve it over time toward what we might want from the "one true Rust Specification").
- We reevaluate this question in the future.

TC: On the one hand, "choose both" is the easy answer, and that's generally unappealing. But there are some merits to it in this case. For one, as Pietro has emphasized, keeping the FLS up to date is apparently easy (he's said it took one day to update it across many Rust versions). This ease is due to its superficial coverage. And yet it's good enough for its niche. Though it would mean two documents, there's some appeal in maintaining the smallest possible document that satisfies this use case. Anything we do to add depth and volume to the document appropriate for certification will make that certification document more expensive to maintain.

Joel: Maybe we have a central content repository of content to produce context specification versions of the specification.

carbontaniuman: We don't know what the output format is best. Feels we are on the wrong decision vector here.

Connor: Paid workers vs. volunteers are different. We won't know who the volunteer resources are unitl a decision is made here.

Joel: How do we get over that wall of figuring out who the volunteers are?

Pietro: It took 3 people 6 months to get to the FLS. We need paid contributors otherwise it is going to take a long time. Two documents could work, but this may not be the best solution long-term. FLS can be amended to be more deep and not affect its safety criticalness. There is some appeal to TC's proposal and I'll need to think further about this.

Felix: Joel's idea of central repository is a long-term vision, but TC was actually saying we have two distinct specifications and maintain both for now. The FLS and the Reference.

Connor: Suggest doing a C++ Committee style vote (Strong. In Favour, In Favour, Neutral, Against, Strong. Against for each proposal) as it doesn't seem like we'll necessarily get to full consensus.

(The meeting ended here.)

---

## MiniRust Update

## Core Library Fit