---
title: T-spec meeting 2025-06-12
tags: ["T-spec", "meeting", "minutes"]
date: 2025-06-12
discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-06-12/
url: https://hackmd.io/kHnZCXzwTJWsubSd17XVHw
---

Attendees:
- Joel Marcey
- Eric Huss
- Monadic Cat
- Pete LeVasseur
- Tomas Sedovic
- Mara
- Sid Askary
- TC
- Sam Wright
- Niko Matsakis
- Josh Triplett

Regrets:

Agenda:

- Updates to the agenda?
- Naming Discussion Continued (30 minutes)
- Have we met the H1 2025 Spec Project Goal (15 minutes)
- Spec Goals for H2 2025 (15 minutes)
- How to accept new contributors to the Reference (If we have time)

## Updates to the agenda

## Naming Discussion Continued

Start the conversation around the analysis TC wrote up.

- [Document](https://hackmd.io/nqGf4SQ0RoSOCz6NlCpxJA)
- [Discussion](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/On.20.22defining.22.20a.20language/near/523001911)

Joel: Thinking about this more, I don't think we need to necessarily resolve the naming debate today. Determining a path forward for the two documents - FLS and Reference - seems more important insofar that whatever new content and direction we take them could have an effect on the final naming of the documents. The H2 Project Goal discussion feels like a better use of time and resources, at this point. We can continue to discuss and gather information from other sources regarding the name, specifically how important having the word "specification" is to them.

TC: Nell from Microsoft mentioned interest in the specification, and may join us next week after checking further with Microsoft.

Joel: Re naming, we should continue to gather thoughs from other people/companies. Happy to continue the discussion but not necessarily have the resolution in this meeting.

TC: Looked through around 20 lang specifications. C/C++ have particular language for framing the document:

> This document specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, so this document also defines C++. Other requirements and relaxations of the first requirement appear at various places within this document.

TC: For the most part, all the good ones align with this model. The document is specifying the implementation of the language. You specify the minimal representation of what you need to implement the language. To that you need to define the language. To do that you need to specify the complete form and meaning and interpretation of programs written in the language. This is another way of getting at what Ralf is getting at.

TC: I think we can get there from a basic engineering matter: I have a specification, I hand it to a contractor. The contractor delivers something that meets the specification. Then I need to accept it. None of our documents do that. Conclusion: our documents are not specifications.

TC: It's not one of our current goals. It's a huge distance to cover to completely describe the form and interpretation of programs written in Rust.

Niko: What are they if they're not the specification.

TC: They describe the form pretty clearly.

TC: I distinguish between a document "describing" and "being prescriptive". I can say a u16 must be 2 octets. That's normative. But it doesn't define what Rust is.

Niko: We are aiming to specify the language. We have to control our scope but we're aiming to define some set of the language in a thorough way.

TC: When I looked through the language's specifications, their documents are of a different class and aspiration from what we have. When you take the C++ document, you can align an implementation to that and then by definition taht implementation is an implementation of C++.

Niko: I am aspiring to that.

Joel: I don't buy the premise that the definition of "specification" must be what e.g. the C++ spec is. Your definition is stricter than what I have in mind. Once we decide how we'll fill the gaps between FLS and ourselwes, then we're in a better position to figure out whether what we end up having is a specification or not.

Josh: The things you looked at seemed to aspire to the idea of there being more than one implementation of the language. That's not what we're building. If you want to build a Rust language, step one is not the spec but join us here in language.

TC: That gets to what Niko raised -- I'm not sure whether people share that goal or not. We are bound by our screw-ups, when we ship Rust 1.88 we never fix it. But the C++ spec isn't set in stone. They define a new version. Our version of that would be specifying Rust 1.88.

Eric: I'm not sure I understand Josh's point.

Josh: I'm responding to what was in TC's analysis: the notion: if you've implemented the specification, you've implemented the language. That's not what we're aspiring to or in our charter. We're trying to specify the language/implementation we have. TC: the thing you're describing, are you aiming to be able to implement a new language or understand the language we have?

TC: I'd distinguish the goal of being able to support multiple specifications from the specification *defining* the language. Even if you don't support that usecase, if you have such a specification, when someone writes an implementation to it, they will have that language.

Niko: My goal is tell you what the Rust compiler should do. Does it accept this program, what are its semantics? I don't have a goal of supporting alternative specification. I want people to be satisfied with the name and have them the (true) perception that Rust has riggour.

Josh: There's a distinction between "this is more or less complete" vs. "this is declared to be a definition" in the sense of "if you've implement this you've implemented Rust". The former is a matter of completeness -- that is within our goals. We're not there, we're providing enough to be useful but we're not 100% complete. Getting there would be good. I don't know how far we need to get to be able to call this a "specification of Rust". I don't think that necessarily means you'll be able to completely implement Rust according to the spec.

TC: Let's just agree that if it's not shipped by the Rust project will ever be Rust™. Even if it's not a goal of ours to have a document that let's someone to implement a language isomorphic to ours -- if you aspire to a complete definition, there's no way to avoid that outcome. If you're completely describing the form and interpretation of the language then by definition you've met tihs.

Joel: I think when Nell and others come to this meeting and tell us what they want out of the specification will help us what other people will want.

Josh: If the idea is "you should be able to read the document and nothing else" and be able to implement the language, then that's an aspiration we have. But if people do such an implementation and we've fixed a bug, and they've implemented it they can't come to us and say that we've broken the spec because their language now doesn't conform to the speficication.

TC: After doing the analysis, it's clear that this isn't some niche definition of the specification. I'm trying to reconcile what kind of definition of the specification we might have.

Joel: We don't have an agreement on what we mean by "specification". We need to continue this on Zulip.

Joel: I appreciate TC putting this analysis together.

Josh: Disagreement aside, I appreciate all the great work that went into doing the document.

TC: I suspect getting at the interest is more important than the naming. I'm really curious is to see other people's thoughts.

## H1 2025 Spec Project Goal Status

Have we met the goal set out for publishing a rust-lang owned version of the FLS?

[Goal](https://rust-lang.github.io/rust-project-goals/2025h1/spec-fls-publish.html)

[Published FLS](https://rust-lang.github.io/fls)

Joel: When we started, we wanted to integrate the FLS into our processes e.g. what we do with the Reference. But over time we've agreed to stick FLS to its existing processes. So technically, we've shipped the FLS under the Rust project. What do other people think?

Josh: It's good we've got the tooling in place to build the document and that we've sufficiently updated the doc to not say Ferrocene. But I think it would be better to have it at some more official location. Something at the rust-lang.org banner.

Eric: Are you planning to update the document so it doesn't say "this is for Ferrocene"?

Joel: Definitely, there's more we want to do here.

TC: I would prefer to declare victory immediately.

Joel: I think we can declare victory for publication, but Josh's suggestion on publishing it somewhere more visible is good.

TC: I'm fine publishing it at docs.rust-lang.org but then we need to update it into our build processes. But I'm happy with the way it's published that way. We're doing it under RFCs etc. No one's saying those are not official.

Josh: I'm not suggesting is the entire document needs to live at a different location. But if you look at doc.rust-lang.org we have a long list of documents -- some are hosted directly on doc.rust-lang.org, other's aren't. But we should link it from there so it's among all the other lang docs. And also CNAME it to something under the rust-lang.org domani.

TC: There was a Zulip discussion using not having appetite to CNAME the Reference at this moment.

https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Is.20it.20possible.20to.20add.20a.20redirect.20for.20a.20subdomain.3F/with/519745365

Niko: Very differnet set of people read RFCs vs FLS so the fact they're both on github.io isn't necessarily the same thing.

Joel: Niko, how does the whole process of the goal work. How do we declare it's done.

Niko: We post updates on the tracking issues -- those will be posted on our blog post. There's not even a formal sense of whether we've met the goal or not. Now we should decide what we want to do next (in H2).

Niko: I feel we've met the goal.

## Spec Goals for H2 2025

Potential goals for H2 2025

- Gap understanding and filling in the FLS and/or Reference
- Determine feasibility of merging the FLS and Reference

Joel: I'd like to get people's ideas for what we should do in H2 regarding "the spec".

Joel: We should start filling the gaps FLS/Reference gaps and going through the process of figuring out whether we should merge the documents.

Josh: I think picking something reasonable we can get done in the next 6 months is good. The work is ongoing -- we know we'll working on this in the next 6m.

Joel: If we can't verbalize what we want to accomplish in the next six months, then we'll have issues to verbalize what we're trying to do.

Niko: +1

Niko: Last time I proposed the goal to push for merging the FLS and Reference but Josh you pushed back.

Josh: I was observing that I don't think we have capacity to merge the documents in six months and not break some things.

Niko: What concrete thing you think we should do in the next 6 months, Josh?

Josh: Right now we have a specification for a particular version of Rust. We get periodic PRs about updating it to a more recent version of Rust. I'd like us to integrate the processes for updating the specification for each new version into the Rust project similarly to what we do for the Reference.

Josh: Everywhere we currently say "you should update the Reference" we should do the same for FLS.

Josh: This is quite ambitious. Unlike with the reference where we just send a patch. With the FLS there's an expectation on how the document is used for qualification. So we'll need to be able to make it approachable enough so people can make changes while still being able to keep using it for qualification.

Josh: I don't just meant updating it periodically, but getting people to update it incrementally as they make changes to Rust. Update the spec proactively.

Niko: I think that makes a lot of sense. What I'm not completely aligned is whether that's where we'll land. Seems to me we'll be unlikely to get to a point where the outside contributors will update the FLS to the level we need (we're not getting that with the Reference either).

Josh: I appreciate that it may be harder to update the FLS than it is to update the Reference. Is there anyone in the room who feels confident they are able to update FLS?

*Niko raised hand*

Josh: If we have at least 1-2 people outside of Ferrous Systems, we can document this so it's possible to expand the set of people who are able to contribute to this.

Eric: If you mean to have new features blocked until the FLS is updated, you might have a revolt (T: from whom ??)

Josh: This is an incremental process. Step 0: please add a label/ping us if you make a change that likely impacts the FLS. And eventually ask for drafts or hints from what needs writing. As opposed to saying "you must update the FLS".

Josh: Right now we say "you need to update the Reference text" we could change that to "update the Reference and notify the spec team".

Joel: If there are times when the language change would require the same information to the Reference and the FLS, if we could get that done at the same time that would be a win for us. When the items aligned, we should aim for both.

Niko: We have two goal proposals here. I encourage people to write them out.

Joel: Eric, your topic on the people revolting requires further documentation.

*which continues now*

TC: It's not like the whole project revolts at onec. You ask one thing and people start questioning.

Eric: We haven't had a major language changes recently. But we had four recently that came out very poorly. People are getting angry because we're requestiong because we're requeesting that they specify whaat the feature does. I'm at the front line of that anger and woried it'll get to the lang team.

TC: It does come to us.

Eric: The stabilization reports are very far from what's actually being specified. I need to go to the compiler source code. The person requesting the specification may not fully understand the feature?

Josh: This is the first time hearing that people are pushing back about having to update the reference. I'm sorry you're feeling the only person having to deal with that.

Josh: I'm wondering if there are steps we could take that can lower the friction.

Eric: TC has been helpful in clarifying what we need and what needs fixing. And the new stabilization template helps a lot.

Eric: But there's a lot of technical details that aren't explained. The person writing the specification understood the feature very well, but they still didn't know what to do in some areas.

Eric: The way people can help is having synchronous chats. TC and I are spending a lot of time talking synchronously and that helps feel less alone.

Josh: I'd be happy to join in on some of the synchronous chats and provide some additional support.

Joel: Maybe we could separate two meetings out? Have this meeting where we don't do specific items but have another meeting where we go over these issues.

Eric: TC and I have a scheduled time. It works.

TC: Sometimes it takes us over an hour going over one Reference PR. There's an editorial standard we're trying to meet but we can't just look at the diff. Is this even in the right section? Maybe the grammar is fine in isolation but not within the context of the document.

Josh: Fixing any systemic problem that's leading to changes not being suitable to begin with (including describing expectation of grammar, how things get parsed etc.) -- that's the kind of thing we should talk about and bring to lang to get the process change. If we're constantly having clean it up we should look at stopping this being a systemic issue.

TC: We could say that we won't even consider / nominate something from lang until it's described in the Reference. The problem is, you do a bunch of work there, then lang looks at it and we may not accept it. The contributors get annoyed.

Joel: Should we come out of this discussion with there being more people willing to help out?

Eric: I think that would be usable but I'm committing a lot of my time to Rust and this would be more time.

Joel: Could we add more people to the conversation?

TC: We could figure something out. And I'd like to push on the spec team to be able to do some of these reviews during the spec call. To share the context, have people absorb the documentation standards.

Eric: The process thing is difficult. Like TC said: if we ask someone to document something thoroughly, that's a lot of work that can ultimately be rejected by the lang team. The LC suggested in the morning that they'd like to document nightly things. And that would be great, but's a lot of work that can easily change.

Josh: For example, instead of requiring something like an RFC up-front, we could accept a stabilization report that won't get changed later on.

Eric: Do you have a "vibe check" step before stabilization?

Josh: Right now we have a "vibe check" before writing an RFC. The idea of adding a vide check step for adding a stabilization report seems like a good idea.

TC: Honestly, we're mainly interested that everyone is happy. Did you talk to the peple who imlemented this? How does this interact with the trait solver? Not sure the vibes check is enough.

## How to accept new contributors

## How to address target-specific or dependent things like the `breakpoint` example

## Jitsi Chat

Monadic Cat
Monadic Cat says:Heya

10:00

me says:Hello

10:00

me says:
https://hackmd.io/kHnZCXzwTJWsubSd17XVHw

10:00

MC
Monadic Cat
Monadic Cat says:been a while since I popped up at one of these, how's it going?

10:01

me says:Loads of fun as usual, of course.

10:01

MC
Monadic Cat
Monadic Cat says:lol

10:01

avatar
Tomas Sedovic
Tomas Sedovic says:thanks Josh

10:05

N
nikomatsakis
nikomatsakis says:I thought 10 minutes 😃

10:07

me says:I was trying to be semi-realistic Niko 😉

10:07

nikomatsakis
nikomatsakis says:I feel like 10minutes is realistic in a way that 30 might not be

10:07

nikomatsakis says:once we get that deep in...

10:07

what else is there to aspire to?

10:14

nikomatsakis says:(is my enqueued q)

10:14

MC
Monadic Cat
Monadic Cat says:"normative reference" moment

10:15

me says:I do agree that the FLS does not completely define the Rust language in the way the RFC expressed a specification might do.

10:21

me says:Which is why I would never call it the Rust Language Specification

10:22

M
Mara
Mara says:👍

10:22

MC
Monadic Cat
Monadic Cat says:so, this is totally not my place to ask, but maybe this talk about whether something is or is not a specification can be taken async? it looks like there are other important things to get to this meeting, and this feels like a classification argument that'll go long

10:22

me says:I did specifiy to timebox this to 30 minutes. So we haven't completely reached that time yet.

10:23

me says:But yes, I agree, I don't want to spend the entire meeting talking about this.

10:24

N
nikomatsakis
nikomatsakis says:TC: I still want to know what the purpose of the reference IS, if it's not to define what Rust is (which to me means: the meaning/behavior of Rust programs (in last few minutes))

👍

10:27

M
Mara
Mara says:seems to all come down to whether we want the first sentence to be: "This is the definition of the Rust language."

10:27

J
Josh
Josh says:If the thought is "you should be able to read this document and nothing else, and know how your Rust program will behave", that seems like an eventual goal.

10:28

N
nikomatsakis
nikomatsakis says:you implemented v1 of the Rust 1.88 description but not v2

10:31

me says:I feel we are harping on the whole "implementing Rust" piece, but I don't believe a specification has to be something that requires an implementation of Rust itself.

10:31

J
Josh
Josh says:"and you quiz people doing contracts" is a big qualifier there.

10:32

me says:But it practically stands that the FLS meets the definition for the purposes of qualification.

10:33

MC
Monadic Cat
Monadic Cat says:oh hey I hadn't seen
https://rust-lang.github.io/fls/
yet

👍

10:36

so, like, link it and CNAME it

10:42

T
TC
TC says:
https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Is.20it.20possible.20to.20add.20a.20redirect.20for.20a.20subdomain.3F/with/519745365

10:43

J
Josh
Josh says:TC: So, that seems like a decision that was made by the team managing the Reference, about the Reference.

10:44

Josh says:And given that the reference already *has* a home on
doc.rust-lang.org
, that seems fine.

10:44

Josh says:That doesn't seem like it serves to have decided what we should do with the FLS.

10:45

T
TC
TC says:If we CNAME the fls, that'd force our hand on CNAMEing the Reference, is my feeling.

10:45

J
Josh
Josh says:Why?

10:45

T
TC
TC says:Parity.

10:46

J
Josh
Josh says:Again, why?

10:46

T
TC
TC says:It's been a recurring theme, I think, not giving greater prominence to the FLS over the Reference, and a CNAME for one is a lot of prominence that, to my eye, exceeds the prominence of a link on `doc.rust-lang.org`.

10:47

Josh
Josh says:I feel like the reverse is true: if you look at the docs on
doc.rust-lang.org
, most of them live *directly* under
doc.rust-lang.org
, and then there are the weird exceptions that link off elsewhere, like
rustc-dev-guide.rust-lang.org
.

10:48
TC
TC says:I'm in favor of linking to the FLS from that page. My feeling is that's a good starting point and enough to declare some victory here.

10:51

I think there would be plenty of times where the change to the FLS and the Reference may be the same, but just presented in a different way.

👍

10:55

J
Josh
Josh says:@TC: It's at least a next step, and I do agree we should do it.

10:56

Pete LeVasseur
Pete LeVasseur says:Need to drop in ~1 minute for next meeting. Wanted to express thanks to @TC for doing the leg-work to pull together the document and share it.

10:57

nikomatsakis
nikomatsakis says:I have a hard stop but I want to summarize that we have two proposals for goals: (1) prepare a merged document; (2) RFC for FLS integration into process

10:58

nikomatsakis says:I propose this:

10:58

MC
Monadic Cat
Monadic Cat says:outsider question again:
what things require updating the Reference which don't require updating the FLS, or vice versa?

10:58

nikomatsakis
nikomatsakis says:let's each write up a goal doc draft over the enxt week

10:58

nikomatsakis says:and anyone else who has an idea 😃

10:58

MC
Monadic Cat
Monadic Cat says:(also sorry I didn't mean to break up your chain niko)

😂

10:58

Josh
Josh says:Niko: I'd love to collaborate on a draft, rather than writing two drafts...

11:00

nikomatsakis
nikomatsakis says:I want to write a draft because I have a different take and I want to try it

11:00

Monadic Cat
Monadic Cat says:my earlier question is kinda, like, "would tagging about needing reference changes basically imply needing FLS changes, so an FLS tag would be redundant?"

11:01

Josh
Josh says:
https://i.giphy.com/media/5OqXb948EBkyUcnwHt/giphy.gif

11:06

Before the end of the meeitng, I wanted to thank Tomas for taking minutes.

❤️

11:14

J
Josh
Josh says:Hear hear.

11:14

MC
Monadic Cat
Monadic Cat says:Yeah, that's really nice of them, thank you Tomas

11:14

avatar
Tomas Sedovic
Tomas Sedovic says:❤️

11:14