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

Attendees:
- Joel Marcey
- tshepang
- Eric Huss
- Tomas Sedovic
- Jack
- Sid Askary
- Josh Triplett
- Nell Shamrell-Harrington
- TC
- Niko Matsakis

Regrets:

Agenda:

- Updates to the agenda?
- Specification input from other sources (30 minutes)
- Moving on from naming? (10 minutes)
- Drafting H2 Goals (5 minutes)
- Gap analysis for the Reference?

## Updates to the agenda

PR Review

## Specification input from other sources

Joel: Context: this started off the back of the naming discussion. I wanted to hear from people from companies and projects and hear what they'd like to see.

Joel: Chatted with Foundation board member reps from Huawei and Amazon (AWS), the original resource providers for specification work.

Joel: From the Huawei side, they believe a specification for Rust is an important milestone for the future of the language. They would prefer it (in whatever form that takes) be called a specification, but that's not a showstopper. For their work personally, the most important thing is to have stable (almost LTS-like) versions of a specification associated with specific compiler versions.

Joel: From the AWS side (board member of the Rust Foundation -- Seth Markle), they are heavily invested in Rust, including around reasoning and validation of their own code. They see a specification as a document that defines what is and what isn't. Naming is also not a showstopper, specification in the name not required, but thinks the FLS should maybe have safety-critical in the name. A key thing for them is that the FLS and the Reference are not in conflict with each other. Liked the idea of potentially merging the docs. Will talk to more people internally about other thoughts on the specification work.

Joel: Both AWS and Huawei said they will look to send representatives to the `t-spec` meeting (similar to Nell and Microsoft) to go into further details and have more of a back and forth.

Niko: That all sounds accurate but I'm not going to represent AWS here. They'll send a representative.

TC: When talking with these stakeholders, we'll want to ask what the properties and characteristics they want from a document are. Similarly, it'd be good to know what their use case is, as that implies certain characteristics.

Nell: Talked to some colleages to make sure I'm representing their viewpoint. Specification: a document from which an implementation of the language can be built. Additionally (but much more difficult) as a way to verify an implementation. We see a Reference as a working implementation of a specification. The naming isn't as important. We applaud and stand by the initiative because it's a clear sign of maturity of the ecosystem.

Niko: How much is the "LTS" angle relevant to you?

Nell: LTS is very much desired but we see it as separate.

Niko: Do you want the spec to capture a point in time as Rust was at a given version, or a living document?

Nell: We'd like to see a versioned living document.

Joel: You've mentioned specification to be something that someone can build a version of Rust. That's not something we're focusing on producing right now. Does that matter to Microsoft? That what we produce at least now won't be utilised to produce an alternative version of Rust. Would Microsoft be disappointed?

Nell: That's something we'd like to see in the future. But there wouldn't be a controversy if the first iteration wasn't that.

Josh: I'd love to hear more about what LTS means to you, Nell and to Microsoft. We've heard from a lot of people that Rust needs an LTS on behalf of other people but not from people who actually need it. Can we talk offline?

Nell: I'd be happy to do that.

Josh: When you talk about being produced an alternative implementation of the language: we've heard people say that before for multiple different reasons. Is this about having the language having the option in case it's ever needed? Or is this a "we wish to do that".

Nell: At this point: "It ought to be possible" (not something we plan to do right now). There's not a Rust# plan, sharp things shouldn't be rusty. :-).

TC: Can you provide a bit more context on the usecase here. Who are the people you talked to: what they're working on, why do they want these properties, how does this help their work.

Nell: Our Developer Devision (DevDiv) are responsible for all the languages used as Microsoft. Microsoft uses a ton of C++ and this is the division responsible for Visual Studio and all the tools. There's of course .Net, C#, Go, Python (various ones). Rust is a supported language within Microsoft, but they're more looking at the specification / reference as a sign of maturity within the ecosystem.

Josh: You've mentioned there's a list of criteria of the signs of a mature language. Would you be able to share some of that?

Nell: I'd be happy to ask if that can be shared.

TC: Could you talk about whether there's any degree to which what we're doing here could help with Rust adoption in larger products such as Office?

Nell: The document is helpful in making the case for Rust adoption. In terms of software company, Microsoft is very old, people are used to doing C++. A part of what I did was convincing them that it's okay to use Rust. They're used to using debuggers which originally was very limited. This has now gotten better. The main hindrance is more inertia. But we are moving forward.

Joel: FLS: do they find that there are specific gaps to serving the qualification purposes?

Nell: I'm going to ask about this within Microsoft.

TC: Perhaps you could talk about DevDiv, in terms of how does that interfaces with the rest of Microsoft. What does it mean, in terms of internal adoption or other use, if DevDiv is happier with Rust?

Nell: DevDiv is a huge organisation. At the moment it's mainly about suporting Rust internally. We have an internally-supported toolchain that needs to be evaluated and supported. That's what DevDiv is mainly focused on at this point.

Niko: One important bit of context is that a lot of Rust usage occurs in places that don't use DevDiv such as Azure.

Nell: Azure works with DevDiv. But yes, Azure has a lot of Rust usage. Other places too (Office).

TC: One thing to think about, in terms of Rust adoption, is how we can support companies in exposing Rust SDKs to their products. I wonder whether there are opportunities here similar to AWS' support for Rust in their SDKs.

Nell: There is an Azure SDK for Rust -- becoming officially supported within Microsoft.

## Moving on from naming?

Joel: Suggests the Reference stays the Reference, or Rust Reference maybe more explictly.

Joel: We should rename the FLS to something Rusty. Rust Safety-Critical/Qualification Manual/Reference?

Josh: Not "reference", let's avoid adding confusion there. But :+1: for adding "Rust", and "Safety-Critical" and/or "Qualification", to the FLS.

Josh: If you're going to name it the "Safety-Critical Manual" people would abbreviate to SCM (and pronounce it "scum").

TC: I propose we table the naming discussion from this meeting. We have good input, we can think about it and come back to it in the next meeting. I'm broadly aligned with Joel's proposal.

*Joels agrees, moving on*

## Gap analysis for the Reference?

Josh: Last week, in the course of the naming discussion, TC mentioned the idea of the Reference not covering all of Rust. (That has come up before, as well.) Could we take a moment to talk through what areas of Rust the Reference doesn't currently cover at all, and what areas of Rust the Reference covers incompletely? Would be helpful for making a plan to address those gaps and contribute further.

Joel: As potential context, Eric created this: [Reference/FLS Mapping doc](https://docs.google.com/spreadsheets/d/1FgBYYVY3RtLHZyyy_bCQ-cWmC2nbLsbStgj1OPCeQ3E/)

Josh: That maps between the Reference and the FLS; as far as I can tell, it doesn't discuss what is missing from the Reference that isn't in the FLS either.

Things not covered:
- Borrow checker
- Type inference
- Trait solver
- Operational semantics / dynamic semantics of the language
- Exact behavior of proc macros
- Expansion in general (macros by example is covered, but not things like proc-macros and the general process such as cfg pruning)
- Name resolution

Discussion around const eval

Eric: It's not perfect but the coverage of const eval is pretty good.

Sid: Maybe we should ask Ralf as well?

TC: We have, that's where some of this is coming from.

Niko: It's interesting to catalogue all the gaps. But it'd also be interesting to pick one or two scenarios to focus on.

Josh: Yes, exactly. What would it take for us to address some of these gaps? If we have resources to throw at the reference: where should we throw them?

Joel: For these gaps, we need someone who's experienced and willing to fill these gaps or hire someone who's either an expert or talk to the experts and write the words down.

Josh: If we do bring resources to The Reference, the other thing this will need is additional help reviewing all this. If we provide more to review we must also improve the reviewers' capacity.

Joel: That may actually be the biggest sticking point.

TC: I've recently, based on our discussions, been giving serious thought to, and having discussions with people on, the question of how much money it would take to get a full specification written (e.g. by someone as much like Ralf as possible). In terms of the demands on reviewer bandwidth, it depends a lot on who is writing that document.

Sid: What do we pick as the ideal point of reference to write the reference? "Reverse-engineering" the compiler? Pick a combination of that and updated RFCs coming out of the lang team? What version do we peg it against? How often do we update it?

Sid: To fill the gap: someone needs to go throught the compiler and figure out what's been implemented and will be implemented. What is the golden standard and how would that person/group go about doing that?

Eric: What we've been doing is: look at the compiler source code to understand it, then read the docs and RFCs to understand the broader context. And then talk to the people on the lang team etc. to find out what's actually expected. It's somewhere between "what rustc does" and "what we want to have"

Josh: If we're filling new areas that weren't previously covered, we can look at other documents such as the Rust Book. We can use that as the bare minimum starting point to get an idea of what to cover. And then look at the conversations, RFCs, compiler details.

Sid: And the last part of the question: versioning. What's the gap between what's the current status and what's the desired status.

Joel: The reference lives on as the living document reflecting the current status of the compiler.

Eric: If I were to finish off name resolution, I'd do the it against the current version of the compiler.

Josh: Eric, would you have objections of opening tracking issues against the gaps?

Eric: We have tracking issues (the `New Content` label)

https://github.com/rust-lang/reference/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22New%20Content%22

Eric: Some things like type inferences has seen resistance -- people aren't sure whether it's settled enough.

Eric: There are also small things that can be worked on (e.g. we don't document the default generic) if someone's interested in contributing.

Josh: Makes sense, if someone wants to become a new contributor it makes sense that they should start with a smaller gap rather than deciding their first contribution should be a brand new chapter.

TC: Eric is currently working on refreshing our documentation on attributes. We're normatively documenting the smallest set we're happy with. And then we're describing in admonitions things that are currently done now but that may later changes. E.g. yesterday we were talking on the lang call about the drop order not being exactly what we want. We'd want to document what it is, but suggest to people to not rely on it.

Niko: I just want to say: I don't think us documenting something doesn't mean we'll never change it. It's a living document, it adapts. It used to say we do things in one way, now it does something else.

Josh: That's especially true if we document something that Rust doesn't do right now.

Niko: I'd love to see us document invariants and goals that any implementation would need to do. That would be very useful to the types team where we could use this to fuzz things.

TC: I agree documenting the type system invariants is a great place to start. I do think it should be written down. When we change the language there should be a diff in the Reference.

Niko: Think of it from the safety critical point of view: when they've qualified a version of Rust and a new one comes out they want to see the diff and see if that's something they need to requalify.

Josh: Agreed and I think that's something we have a good idea of when we're writing this down. We know which areas are often changing. We could make it explicit in the doc that some areas are changing frequently. Hesitating to writing something down because it'll change in the future is not great. Document the current behavior.

Eric: And we already do that in many places.

## PR Review

Ralf's PR for const-eval. https://github.com/rust-lang/reference/pull/1859

~~"The type of a `const` item cannot contain a mutable reference."~~

TC: We've rejected type-based reasoning. That's why RalfJ is phrasing it the way he does.

Eric: would it be more like this?

"The final value of a `const` item cannot contain a mutable reference."

Niko: The diff looks clear. What is the question exactly?

Eric: To me, removing the rule that const not having anything mutable -- I couldn't find anything that said you couldn't do that.

Niko: Can you not do that?

Eric: As far as I know, you can't have a mutable reference to const.

Niko: I that because you can't have it due to the type?

Josh: You can't have a const whose type literally has a `&mut`. Whether that's a type or a struct whose field has a mutable reference.

Josh: It's okay if you have it on the right-hand side and it's okay if you have an interior mutability even though you can't change anything.

TC: Here's something we do accept:

const C: Option<&mut ()> = None;

Niko: I think this comes back to the value vs. type distinction. Seems like we should just ask Ralf this?

Eric: He responded to my question on the PR: "we just throw an error if we find any mutable reference in a const".

Niko: I feel that should be a separate rule. The traversal of the value cannot find `&mut`. Seems like you're right that it's not covered by the language Ralf provided.

Josh: It doesn't seem quite accurate to say you can't find a mutable reference. If your mutable reference is being masked by an immutable reference, it's effectively an immutable reference.

Experiments:

// ERROR: it is undefined behavior to use this value
static mut FOO: u32 = 22;
const X: &'static u32 = unsafe { &mut FOO };

// This is an example from 140942
static mut FOO2: u32 = 0;
const C2: &'static u32 = unsafe { &mut FOO2 };

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=56752fd1114bfa745c2a59d86cd3a670

https://github.com/rust-lang/rust/pull/140942

Niko: WASM spec is a good model to mimic, for it is readable while being (reasonably) precise

[A comment on the PR](https://github.com/rust-lang/reference/pull/1859#issuecomment-2988627253) posted during the meeting

## Drafting H2 Goals

Postponed until later

## Jitsi Chat

https://hackmd.io/UVJf7ZViQNu9MmiKeXTugw

10:01

N
nikomatsakis
nikomatsakis says:gonna get some coffee

10:20

nikomatsakis says:brb!

10:20

J
Josh
Josh says:👏

10:30

avatar
Tomas Sedovic
Tomas Sedovic says:Nell, I'm sorry: what was it you said about specific gaps in FLS?

10:30

Tomas Sedovic says:missed that while taking notes

10:31

NS
Nell Shamrell-Harrington
Nell Shamrell-Harrington says:That is something I am going to ask about within Microsoft 😃

10:31

avatar
Tomas Sedovic
Tomas Sedovic says:thank you!

👍

10:31

NS
Nell Shamrell-Harrington
Nell Shamrell-Harrington says:😀

10:32

Nell Shamrell-Harrington says:Never find a more wretched hive of scum and villiany...

😂

10:32

N
nikomatsakis
nikomatsakis says:Rust Safety Critical Reference

10:33

How about documenting the standard library as something that could potentially be moved into the Reference?

10:37

J
Josh
Josh says:@Joel: I don't think we'd want to be redundant with the rustdoc; is there something that *wouldn't* be covered by the rustdoc?

10:38

me says:I don't recall fully - was there some sort of idea that maybe we see about merging rustdoc content into the Reference?

10:40

J
Josh
Josh says:@Joel: Shall we move that from chat into voice?

👍

10:41

👍

10:44

N
nikomatsakis
nikomatsakis says:Time check: Didn't TC want to get to some PRs etc?

10:45

tshepang
tshepang says:what is the current state of funding... afaik, only joel is paid is paid to work on the spec, and rest is volunteering

10:49

Technically, the ring-fenced spec funding has run out. So in some ways I am volunteering too but within the scope of more my general Foundation role.

10:51

Josh
Josh says:👍

10:55

Nell Shamrell-Harrington
Nell Shamrell-Harrington says:got to drop, great to see you all and thank you for the invite!

10:59

J
Josh
Josh says:
https://github.com/rust-lang/reference/pull/1859

10:59

nikomatsakis
nikomatsakis says:const X: &'static u32 = &*&mut 22;

11:04

nikomatsakis says:"mutable references are not allowed in the final value of constants"

11:04

J
Josh
Josh says:This is, though:
const C2: &'static u32 = unsafe { &mut FOO2 };

11:04

nikomatsakis
nikomatsakis says:const X: &'static u32 = &*&mut 22;

11:04

nikomatsakis says:"mutable references are not allowed in the final value of constants"

11:04

J
Josh
Josh says:This is, though:
const C2: &'static u32 = unsafe { &mut FOO2 };

11:04

Tomas Sedovic
Tomas Sedovic says:I'm going to have to drop, sorry!

11:08