---
title: T-spec meeting 2024-10-03
tags: ["T-spec", "meeting", "minutes"]
date: 2024-10-03
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-10-03
url: https://hackmd.io/r1hgOFLbRvyi_vldMGnXnA
---

Attendees: Joel Marcey, Pierre-Emmanuel Patry, Connor Horman, Eric Huss, Monadic Cat, pnkfelix, TC, Skade (Florian Gilcher), Niko, Mario Carneiro, Sid Askary, carbotaniuman

Agenda:

* Integrating Ferrocene into the Project (special guest Florian Gilcher)

## Introductions

Joel: Coming from the heated meeting last week, ensure that all participants are respectful, raise hand and work towards driving consensus.

## Integrating Ferrocene

Joel: ...

pnkfelix: If the project was going to take on the FLS, Ferrous has already made a qualified toolchain on the spec, and what does it look like if we make changes to the spec for Ferrous.

Skade: Ferrous considers themselves a downstream. Changes to the specification would appreciate if we kept that in mind because there are users.

Skade: Need a spec for the qualification. Use tests to ensure compiler meets a description. Whatever the description document is minimal.

Eric: Project does things for themselves. This is different because of business interests. How much do we have to get people outside the Project on board with the specification changes.

TC: For every downstream user, there are two costs to change. There's the cost to update documents to match citations. The other cost is to pay an assessor to review the changes. Larger changes cost more to requalify, and this cost is quantifiable.

Joel: If the project manages the specification, then we can control how these are rolled out.

Connor: If the language changes, the spec has to change. Of course, making large stylistic changes would incur these changes.

TC: The editorial changes -- e.g., things we might do to make the spec better for users not interested in qualification -- are what we have in mind here.

Niko: What is qualified and brought to the assessor, doesn't have to be the same artifact that we produced. It would nice if it was largely derived from what we produced. What do the assessors actually need.

Niko: There would be a growing need to fork. It sounds like folks are saying that we should just fork now. Are we going to have the safety critical work produced by a spec that is produced by the Project?

Skade: Qualification is a bit of red herring. There are parts that assessors care about and some that don't. Non-normative don't care. They care about two things: traceability - is this tested. Second, is the spec covering for the parts we need.

TC: Let's say we write the borrow checker rules down normatively. Does it cost Ferrous more money?

Florian: No, as long as it can be traced. And does the assessor actually need to see it? Specificationa and compiler are there to determine friction points.

Florian: Assessor asks if Ferrous if is capable of coping with what upstream does.

TC: If were to write down 15K words about some subject normatively in the spec, any subject, perhaps one that may not be applicable to Ferrous or safety critical, does it create a cost in terms of the assessor needing to parse through that? That is, if we were to double the word count of the FLS in ways that are important to the Project, but not Ferrous, is that a problem with respect to cost, or are they invariant to that?

Florian: Not really. Relatively invariant to that. Better to have things more specified than not. Ferrrous would like to be involved in these things.

Niko: Clarification - if we add more material, can Ferrous exclude that material if it is not relevant, even though we may try to do so in a traceable way?

Florian: Yes, Ferrous can make an argument that additions are not relevant.

Florian: FLS is written for writing a qualified ccpmpiler, but doesn't need to stay that way.

Niko: What stability guarantees are we making to the consumers of the spec? It would be useful to Ferrous that traceability is preserved. And who cares about them? And how is the work being maintained being funded?

Florian: Traceability from the spec side is that the hooks are there and Ferrous can point to a state in the spec and tooling can be used to do things. It is the work of Ferrous to fill in gaps of testing. The spec should be easy to consume for their needs.

Joel: RFC says document current state of rustc and support safety critical.

pnkfelix: But that doesn't preclude us from looking into the future.

Joel: Agree, but those could be labeled differently where Ferrous and safety critical doesn't need to care about those at a certain point in time.

TC: While we have Florian here, we should discuss:

- What time pressures are there and what effect does our timeline have?
- E.g., if we were to publish a spec today, when would downstreams like Ferrous Systems migrate to it?
- If we were to adopt the FLS as a second document, as we had discussed previously, what kind of support might Ferrous Systems be able to offer in maintaining and improving it?

pnkfelix: Didn't appreciate a concrete problem -- we adopted one strategy earlier in the year that we were trying to get to a specification written by the Project and we started the reference. And we didn't choose the FLS because it would have taken too much time to get where we wanted to be. The problem is that there are real customers using the FLS - is compatibility with the FLS part of our scope?

pnkfelix: Is that problem something that a `t-spec` team has the responsibility to solve?

skade: From Ferrous' system point of view. Changes between Project and Ferrous work can be pretty low. There is not a lot of pressure.

skade: The problem is that Rust is moving in places that are not visible to the Project.

skade: Also, engineers at Ferrous have already written a spec and they don't want to start from scratch again.

skade: Ferrous can offer the produced labor to the Project.

TC: If the project produced a specification that equals or exceeds the FLS but is entirely different than the FLS in structure, what are the effects of that?

Florian: The issue could be that vendors are building tooling based on the semantics of the FLS.

Florian: Incentive for using a spec coming out of the Project is that it is the main spec.

TC: What support might Ferrous Systems be able to provide the Project if we adopt the FLS?

Florian: Education (not super married to sphinx, but a little bit with rST), cannot offer engineering support without funding. Can help with licensing and copyright. We don't want to dump on the upstream.

TC: We can discuss the resources that Ferrous Systems might be able to offer offline, and it would similarly be good to get clarification on those licensing matters, as that would be a pressing blocker.

Connor: Can there be a problem with two documents? One that is not for safety critical - from the Project. The other that is for safety critical - that is from the Project or 3rd party.

Connor: Agrees that adopting the FLS is within scope. But can we change the scope?

Niko: The scope is what is at this point, at least right now.

Niko: Two hats. Not getting value for the funding of the spec. The other hat, are we meeting the customers needs?

TC: The direction the team had taken was a more long term one of adopting the Reference, as the Reference better addressed our other target users, and moving it toward being acceptable for safety-critical. Clearly the FLS already supports safety-critical, so if we started with that, it would serve those customers more quickly, but then (in a one-document world) we'd need to extend it to support our other target users. There are tradeoffs here, and I'm interested in, Niko, your view on that.

Niko: Wants this to be more deliverable based and it seems that FLS would be a good starting point since it already exists and being used.

Eric: Believes that we have a deliverable and have had for a while.

Eric: If we take FLS, who is responsible for the review work? Not just new content review, but existing FLS content review?

Niko: Don't mean to imply there wasn't great work of the Reference. But we are also trying to grow the reference to meet the needs of the spec and safety critical. The goal is to marry the FLS and reference in some ways. Might be easiest to integrate the Reference into the FLS.

Florian: Also appreciates the Reference. THe FLS wouldn't exist without the Reference.

Florian: The FLS has a lot of use cases covered.

Niko: Would love a spec goal for the Project for 2025.

Joel: I feel we have enough data to make a decision from the `t-spec` team.

pnkfelix: No further questions

Eric: Critical question on who is going to do the review work of the FLS. Doesn't want to be the one reviewing the FLS.

TC: We appreciate the patience and support of Ferrous Systems in the spec team's efforts as we work to find the right direction for Rust.

Thanks everyone for attending the meeting.

## Chat

pnkfelix
pnkfelix says:Joel: Maybe announce that people should mute themselves if they are not speaking, especially if they are in a noisy environment
8:05

pnkfelix says:(I'm going to start proactively muting people with background noise)
8:14
S
Skade
Skade says:sorry, that may have been me
8:15
P
pnkfelix
pnkfelix says:thanks Florian
8:15
S
Skade
Skade says:i'm away for a second to plug in power, i'm listening
8:32
avatar
Connor Horman
Connor Horman says:I would also caution us against deliberately blinding ourselves to the future.
8:34
avatar
Niko Matsakis
Niko Matsakis says:( is there a hackmd for this meeting? )
8:39
avatar
Connor Horman
Connor Horman says:
https://hackmd.io/r1hgOFLbRvyi_vldMGnXnA

8:39
avatar
Niko Matsakis
Niko Matsakis says:thanks
8:39
Niko Matsakis says:I'd like to see the "options" laid out
8:39
Niko Matsakis says:pnkfelix++, agree, get aligned on goals and what problems exist in meeting those
8:40
me says:To be clear on my position as a t-spec team member, I answer the question from Felix as a yes - I believe it is our scope to ensure that our spec has compatibility with the FLS given that the FLS is the de-facto spec being used in the real world already and we shouldn't have two fractured specs, one of which the Project does not have influence over.
8:57
me says:And it fits directly with in the scope of the spec RFC as well.
8:57
me says:Just a meeting process note - we are over time from our normal 60 minutes.
9:02
me says:I am happy to stay longer, but I understand if people have to leave.
9:02
avatar
Niko Matsakis
Niko Matsakis says:I can stay somewhat longer
9:03
avatar
Connor Horman
Connor Horman says:I'm not staying for another 2.2 hour meeting 😛
9:03
me says:That's the question I wanted to have answered TC, so I will lower my hand.
9:04
MC
Monadic Cat
Monadic Cat says:(okay for the last few minutes I lost track of the conversation while writing this)

I think I'm interested in hearing about how Ferrous Systems is uneasy about providing the FLS for people, because the easiest path I see is: 1. Take the FLS and make it the official Rust Project recommendation for projects that need ISO 26262 qualification. 2. Make the Rust Spec for other purposes- aka, an actually useful document for keeping track of what the language really is and for being referenced by all developers. 3. Make keeping the FLS up to date a separate piece of ongoing work, try and solicit help from both Ferrous Systems and any other organizations that are interested in having an Official Safety Critical Document for Qualification Purposes.
9:07
avatar
Connor Horman
Connor Horman says:I do have some scope changes I want to make, but none immediate - something I want to persue after we've met our current scope.
9:10
me says:I truly think we can accomplish what we want to achieve with the FLS by adding content we want to add to make the spec more useful for a generalized audience.
👍
For review of new content, won't that problem occur whether we use the FLS or with our current plan? I agree there is a potential additional resource requirement of reviewing the FLS if we bring in the project.
Niko Matsakis
Niko Matsakis says:Connor: initially, it's inevitable that there'll be multiple docs. In the fullness of time, "DRY". We're going to want a "source of truth" eventually.
9:26

Niko Matsakis says:but anyway I feel like every spec has bugs too, there are always lots of different docs with their own take...including the rustc source code...
9:27
avatar
Connor Horman
Connor Horman says:I'm going to drop at or before :33.
Connor Horman
Connor Horman says:My opinion as a T-spec/contributor is that I favour TC's two document model at this time.
9:31
avatar
Niko Matsakis
Niko Matsakis says:TC: my general take is that we should be fwd looking 😃 I didn't understand the conflict so I wanted to dig into specific examples, but what Florian said is roughly what I would expect.
9:31