---
title: T-spec meeting 2025-05-29
tags: ["T-spec", "meeting", "minutes"]
date: 2025-05-29
discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-05-29/
url: https://hackmd.io/_e24RYvXQQC6ahQViFjTvw
---
Attendees:
- Joel Marcey
- Pete LeVasseur
- Sid Askary
- Jack
- Mara Bos
- Josh Triplett
- TC (for the second half)
Regrets:
- Niko Matsakis
- TC (for the first half)
- Eric Huss
Agenda:
- Updates to the agenda?
- Publishing the FLS / specification
- Calling the FLS a "spec"
- Seeking `t-lang` signoff
- FLS / Reference Mapping Quick Look
- Issues/PR review
## Updates to the Agenda
No updates
## Publishing the FLS / Specification
Where do we publish the specification? At what URL? rust-lang.org or doc.rust-lang.org ? `/spec`?
TC (ahead of call): For now, I think it's fine where it is at <https://rust-lang.github.io/fls/>. This isn't that unusual for us. We publish the RFCs repo, e.g., at <https://rust-lang.github.io/rfcs/>. If we do later merge the FLS into the build/release process for `rust-lang/rust` like the Reference is, then it should live under <https://doc.rust-lang.org/> just as the other documents in that state do.
See also the recent discussion where, on lang-docs, we decided for now against adding `reference.rust-lang.org`:
<https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Is.20it.20possible.20to.20add.20a.20redirect.20for.20a.20subdomain.3F>
> Eric and I talked about this on Tuesday in the lang-docs call. It's a reasonable idea, and it's something we'll keep in mind, but we didn't have appetite for doing this a the moment. Among the questions we considered were "where do we stop if we do this?" We have a lot of books and materials. The Reference is pretty uniquely important, but at the same time, it's pretty nice for public-facing documentation to live consistently under `doc.rust-lang.org` and to follow the same systems e.g. with respect to versioning.
Josh: :+1: for doc.rust-lang.org, but also, note that https://www.rust-lang.org/learn exists and links to a subset of documentation. It doesn't need to get linked from there, though, since it's not a doc to learn Rust with.
Josh: If this is going to be a Rust Project document, it should live with the Rust Project documents.
Mara: It is called the Ferrocene Language Specification right now. It is now in the Rust Project and it is a little weird that it is still called Ferrocene. "Ferrocene Language" was just a 'hack' to say Rust without saying "Rust", basically. We don't need that anymore. Also, less likely for people in the Rust project to contribute to it if it's called "Ferrocene Language Spec".
Joel: To me, the term "fls" doesn't mean anything. I would like it named something that is meaningful like "spec" -- or something similar -- like the Reference means something.
## Calling the FLS a "spec"
Many people are asking for this to be called a "spec" (not just "fls"). (Feedback received through various channels, including feedback to Foundation, and feedback at RustWeek.) Are there concerns about calling it a "spec"? What process should we follow for deciding to call this a "spec"?
Formulating milestones to get us towards a 1.0 (from let's say a 0.3) and having them published as Rust Project goals.
TC (ahead of call): I'd be interested to know more about the nature of and motivations behind this feedback. I.e., who is asking for this, and why?
For the moment, in the absence of understanding a compelling motivation for doing this, I'm pretty happy with calling it the FLS, and yes, I'd probably have concerns with calling the FLS the spec for Rust.
We don't know yet how things are going to play out here, and calling the FLS the spec, in my view, creates an expectation about the present state of things that is misleading, and creates an expectation about the future on which we might not follow through.
It's entirely possible, e.g., that along our current trajectory of continuing to improve the Reference, we will subsume the use cases for the FLS, and will provide a migration strategy for users and qualifiers. In that world, I don't think we would have done ourselves any favors, in PR terms, by calling the FLS a spec and then "deprecating the spec".
This is in part simply a resource question. We don't have an army standing by to improve the FLS, and the resources of the Project are focused on improving the Reference, so it's just not clear to me that we have any plan for making the FLS much more or much different than what it is today. Today, the FLS provides obvious value to certain users, but without the integration into Project processes and wide engagement from experts within the Project, it's clearly less normative than the Reference is. So it would be misleading, in my view, to call the FLS the spec for Rust, and without some step function in resources dedicated to the FLS, I don't clearly see a plan for changing this.
It's been mentioned to me that, "well, if we call it a spec, then we'll be able to attract those resources." Probably I want something more concrete here in the way of assurances.
There's a human aspect that concerns me here too. People do things within this project because they think others value those things. With the bulk of human effort within the Project being directed at the Reference, and without a concrete plan to make the FLS into more than what it is, it would just seem odd to me for our team to give the FLS the "primo" name and to thereby make it seem like we're betting the farm on it. It just seems that might make people working on the Reference feel not so valued.
Josh: To build consensus - the original RFC said to create a `t-spec` to work and check back with `t-lang` to make sure the approach is correct.
Josh: The [spec RFC](https://github.com/rust-lang/rfcs/pull/3355) promised to deliver a specification.
Joel: We have two documents that are really good and really get to the point of where we want to be with a specification, even if not perfect.
Josh: What version of Rust does the current FLS track?
Joel: I think 1.84, but would need to verify.
(Lots of discussion...)
TC (in summary): Where we landed is that all of us on the call were OK with framing the Reference as "the specification of Rust" and the FLS (as currently named) as "the qualification specification for Rust", and for documenting this at the top of the Reference with a link to the other document for people looking for a document for qualification purposes.
On the name of the FLS, we discussed calling it the "Rust Qualification Specification". With the framing as above, that might be OK, but I wanted to reflect further on the naming before committing to this. Others were OK with this naming.
Josh pointed out that <https://docs.rust-lang.org/> contains the language:
> The Reference is not a formal spec, but is more detailed and comprehensive than the book.
I hadn't noticed that; if I had, I would have updated that when making the change to remove apologies about the Reference (statements about what it is not), and probably I consider a change to this language to fall out from that other FCP.
We talked about reorganizing that page to have a top-level section for "specifications", and to put both the Reference and the Rust Qualification Specification under it with the framing described above. Josh is planning to put up a PR to that effect.
Reflecting on this all now after the meeting, I do have one additional concern I'd want to talk through with the team. In framing the FLS as the Rust Qualification Specification, and in pointing people toward it if they want a document for qualification, it suggests to people looking to do a new qualification that they should look to the FLS. But even today, I'm not sure that's what we want. Obviously if you're using a toolchain that was qualified with the FLS, that's what you want. But if you're embarking on a new qualification effort today, I'm not actually sure that we would want people to use the FLS for that. At least, given the recent changes we've made to the Reference to better support qualification, it's not entirely clear to me why someone shouldn't prefer to use the Reference for this purpose if unencumbered by existing qualification work -- I'd be curious to hear if there are remaining items here other than what needs to be done to complete the test coverage.
## Seeking `t-lang` signoff
When and how should we seek lang signoff, per our charter? This ties into the above question.
TC (ahead of call): The spec team needs approval from lang when doing something that could be seen as making a new normative statement about the language.
Most directly, that happens when adding some claim about the behavior of the language that could be read as a guarantee when it's not obvious that the lang team has specifically approved that guarantee, e.g. by accepting via FCP a stabilization report that specified that behavior.
More generally, anything that could be seen to make a class of claims seem more normative should be approved by the lang team. E.g., the recent PR to remove a set of outdated caveats related to the degree to which the Reference is normative (<https://github.com/rust-lang/reference/pull/1792>) was done via lang FCP, and I think that was necessary and appropriate.
Concretely, I'd expect a lang FCP before we call something a spec.
Josh: I'd expect that as well, and I think we should do that.
## FLS / Reference Mapping Quick Look
https://docs.google.com/spreadsheets/d/1FgBYYVY3RtLHZyyy_bCQ-cWmC2nbLsbStgj1OPCeQ3E/
| Reference | FLS |
|--------------------------------------|------------------------------------|
| | |
| Introduction | 1. General |
| | 1.1. Scope |
| | 1.2. Versioning |
| | 1.3. Definitions |
| | |
| 1. Notation | |
| | |
| 2. Lexical structure | 2. Lexical Elements |
| | |
| 2.1. Input format | 2.1. Character Set |
| | |
| 2.2. Keywords | 2.6. Keywords |
| | |
| 2.3. Identifiers | 2.3. Identifiers |
| | |
| 2.6. Tokens | 2.4. Literals |
| | |
| 2.4. Comments | 2.5. Comments |
| | |
| 2.5. Whitespace | 2.1. Character Set |
| | |
| 2.6. Tokens | 2.2. Lexical Elements, Separators, |
| | and Punctuation |
| | |
| | |
| | |
| 3. Macros | 20. Macros |
| | 20.3. Macro Invocation |
| | |
| 3.1. Macros By Example | 20.1. Declarative Macros |
| | 20.4. Macro Expansion |
| | 20.5. Hygiene |
| | |
| 3.2. Procedural Macros | 20.2. Procedural Macros |
| | |
| | |
| | |
| 4. Crates and source files | 18. Program Structure and |
| | Compilation |
| | 18.1. Source Files |
| | 18.3. Crates |
| | 18.4. Crate Imports |
| | 18.5. Compilation Roots |
| | 18.7. Program Entry Point |
| | |
| | |
| | |
| 5. Conditional compilation | 18.6. Conditional Compilation |
| | |
| | |
| | |
| 6. Items | 3. Items |
| | |
| 6.1. Modules | 18.2. Modules |
| | |
| 6.2. Extern crates | |
| | |
| 6.3. Use declarations | 14.7. Use Imports |
| | |
| 6.4. Functions | 9. Functions |
| | |
| 6.5. Type aliases | 4.10. Type Aliases |
| | |
| 6.6. Structs | 4.5. Abstract Data Types |
| | |
| 6.7. Enumerations | 4.5. Abstract Data Types |
| | |
| 6.8. Unions | 4.5. Abstract Data Types |
| | |
| 6.9. Constant items | 7.1. Constants |
| | |
| 6.10. Static items | 7.2. Statics |
| | |
| 6.11. Traits | 4.13. Traits |
| | |
| 6.12. Implementations | 11. Implementations |
| | 11.1. Implementation Coherence |
| | 11.2. Implementation Conformance |
| | |
| 6.13. External blocks | 21.2. External Blocks |
| | 21.3. External Functions |
| | 21.4. External Statics |
| | |
| 6.14. Generic parameters | 12. Generics |
| | 12.1. Generic Parameters |
| | 12.2. Where Clauses |
| | 12.3. Generic Arguments |
| | 12.4. Generic Conformance |
| | |
| 6.15. Associated Items | 10. Associated Items |
| | |
| | |
| | |
| 7. Attributes | 13. Attributes |
| | 13.1. Attribute Properties |
| | 13.2. Built-in Attributes |
| | |
| 7.1. Testing | |
| | |
| 7.2. Derive | |
| | |
| 7.3. Diagnostics | |
| | |
| 7.4. Code generation | |
| | |
| 7.5. Limits | |
| | |
| 7.6. Type System | |
| | |
| 7.7. Debugger | |
| | |
| | |
| | |
| 8. Statements and expressions | |
| | |
| 8.1. Statements | 8. Statements |
| | 8.1. Let Statements |
| | 8.2. Expression Statements |
| | |
| 8.2. Expressions | 6. Expressions |
| | 6.1. Expression Classification |
| | 6.21. Expression Precedence |
| | 7.3. Temporaries |
| | |
| 8.2.1. Literal expressions | 6.2. Literal Expressions |
| | |
| 8.2.2. Path expressions | 6.3. Path Expressions |
| | |
| 8.2.3. Block expressions | 6.4. Block Expressions |
| | |
| 8.2.4. Operator expressions | 6.5. Operator Expressions |
| | 6.23. Arithmetic Overflow |
| | |
| 8.2.5. Grouped expressions | 6.7. Parenthesized Expressions |
| | |
| 8.2.6. Array and index expressions | 6.8. Array Expressions |
| | 6.9. Indexing Expressions |
| | |
| 8.2.7. Tuple and index expressions | 6.10. Tuple Expressions |
| | |
| 8.2.8. Struct expressions | 6.11. Struct Expressions |
| | |
| 8.2.9. Call expressions | 6.12. Invocation Expressions |
| | |
| 8.2.10. Method call expressions | 6.12. Invocation Expressions |
| | |
| 8.2.11. Field access expressions | 6.13. Field Access Expressions |
| | |
| 8.2.12. Closure expressions | 6.14. Closure Expressions |
| | |
| 8.2.13. Loop expressions | 6.15. Loop Expressions |
| | |
| 8.2.14. Range expressions | 6.16. Range Expressions |
| | |
| 8.2.15. If expressions | 6.17. If and If Let Expressions |
| | |
| 8.2.16. Match expressions | 6.18. Match Expressions |
| | |
| 8.2.17. Return expressions | 6.19. Return Expressions |
| | |
| 8.2.18. Await expressions | 6.20. Await Expressions |
| | |
| 8.2.19. Underscore expressions | 6.6. Underscore Expressions |
| | |
| | |
| | |
| 9. Patterns | 5. Patterns |
| | 5.1. Refutability |
| | 5.2. Struct Patterns |
| | 5.3. Binding Modes |
| | 5.4. Pattern Matching |
| | |
| | |
| | |
| 10. Type system | 4. Types and Traits |
| | |
| 10.1. Types | 4. Types and Traits |
| | 4.1. Types |
| | 4.2. Type Classification |
| | 4.12. Type Model |
| | |
| 10.1.1. Boolean type | 4.3. Scalar Types |
| | |
| 10.1.2. Numeric types | 4.3. Scalar Types |
| | |
| 10.1.3. Textual types | 4.3. Scalar Types |
| | 4.4. Sequence Types |
| | |
| 10.1.4. Never type | 4.9. Other Types |
| | |
| 10.1.5. Tuple types | 4.4. Sequence Types |
| | |
| 10.1.6. Array types | 4.4. Sequence Types |
| | |
| 10.1.7. Slice types | 4.4. Sequence Types |
| | |
| 10.1.8. Struct types | 4.5. Abstract Data Types |
| | |
| 10.1.9. Enumerated types | 4.5. Abstract Data Types |
| | |
| 10.1.10. Union types | 4.5. Abstract Data Types |
| | |
| 10.1.11. Function item types | 4.6. Function Types |
| | |
| 10.1.12. Closure types | 4.6. Function Types |
| | 6.22. Capturing |
| | |
| 10.1.13. Pointer types | 4.7. Indirection Types |
| | |
| 10.1.14. Function pointer types | 4.7. Indirection Types |
| | |
| 10.1.15. Trait object types | 4.8. Trait Types |
| | |
| 10.1.16. Impl trait type | 4.8. Trait Types |
| | |
| 10.1.17. Type parameters | 4.9. Other Types |
| | |
| 10.1.18. Inferred type | 4.9. Other Types |
| | |
| 10.2. Dynamically Sized Types | 4.11. Representation |
| | |
| 10.3. Type layout | 4.11. Representation |
| | |
| 10.4. Interior mutability | 4.12. Type Model |
| | |
| 10.5. Subtyping and Variance | 4.14. Trait and Lifetime Bounds |
| | |
| 10.6. Trait and lifetime bounds | 4.14. Trait and Lifetime Bounds |
| | |
| 10.7. Type coercions | 4.12. Type Model |
| | |
| 10.8. Destructors | 15.6. Destruction |
| | 15.7. Destructors |
| | 15.8. Drop Scopes |
| | 15.9. Drop Order |
| | |
| 10.9. Lifetime elision | 4.14. Trait and Lifetime Bounds |
| | |
| | |
| | |
| 11. Special types and traits | |
| | |
| | |
| | |
| 12. Names | 14. Entities and Resolution |
| | 14.1. Entities |
| | |
| 12.1. Namespaces | 14.5. Namespaces |
| | |
| 12.2. Scopes | 14.4. Scopes |
| | |
| 12.3. Preludes | 14.6. Preludes |
| | |
| 12.4. Paths | 14.3. Paths |
| | |
| 12.5. Name resolution | 14.8. Shadowing |
| | 14.9. Resolution |
| | |
| 12.6. Visibility and privacy | 14.2. Visibility |
| | |
| | 15. Ownership and Destruction |
| | |
| | 15.1. Ownership |
| | |
| | 15.2. Initialization |
| | |
| | 15.3. References |
| | |
| | 15.4. Borrowing |
| | |
| | 15.5. Passing Conventions |
| | |
| | |
| | |
| 13. Memory model | 7. Values |
| | |
| 13.1. Memory allocation and lifetime | |
| | |
| 13.2. Variables | 7.4. Variables |
| | |
| | |
| | |
| 14. Panic | 16. Exceptions and Errors |
| | 16.1. Panic |
| | 16.2. Abort |
| | |
| | 17. Concurrency |
| | |
| | 17.1. Send and Sync |
| | |
| | 17.2. Atomics |
| | |
| | 17.3. Asynchronous Computation |
| | |
| 15. Linkage | |
| | |
| 16. Inline assembly | 22. Inline Assembly |
| | 22.1. Registers |
| | 22.2. Register Classes |
| | 22.3. Register Arguments |
| | 22.4. Assembly Instructions |
| | 22.5. ABI Clobbers |
| | 22.6. Assembly Options |
| | 22.7. Macros asm and global_asm |
| | |
| 17. Unsafety | 19. Unsafety |
| | |
| 17.1. The unsafe keyword | |
| | |
| 17.2. Behavior considered undefined | C. List of undefined behavior |
| | |
| 17.3. Behavior not considered unsafe | |
| | |
| 18. Constant Evaluation | 6.1. Expression Classification |
| | (6.1.2) |
| | |
| | 21. FFI |
| | |
| 19. Application Binary Interface | 21.1. ABI |
| | |
| 20. The Rust runtime | |
| | |
| 21. Appendices | |
| | |
| 21.1. Grammar summary | |
| | |
| 21.2. Macro Follow-Set Ambiguity | |
| Formal Specification | |
| | |
| 21.3. Influences | |
| | |
| 21.4. Test summary | |
| | |
| 21.5. Glossary | B. Glossary |
| | |
| | A. Licenses |
| | |
| | D. FLS Changelog |
## Issues/PR review
Reference PRs waiting for review: https://github.com/rust-lang/reference/pulls?q=is%3Aopen+is%3Apr+label%3AS-waiting-on-review
Reference Issues Unlabeled: https://github.com/rust-lang/reference/issues?q=is%3Aissue%20state%3Aopen%20no%3Alabel
FLS open PRs: https://github.com/rust-lang/fls/pulls
FLS open Issues: https://github.com/rust-lang/fls/issues
- Difficulty / Importance labeling?
- Labeling FLS issues and PRs?
## Jitsi Chat
https://hackmd.io/_e24RYvXQQC6ahQViFjTvw
9:58
J
Jack
Jack says:+q
10:12
Jack says:Whoops
10:12
Jack says:+1 to rename
10:12
me says:
https://github.com/rust-lang/rfcs/pull/3355
10:23
avatar
Mara Bos
Mara Bos says:👍
10:25
PL
Pete LeVasseur
Pete LeVasseur says:👍
The Specification Formerly Known as the Ferrocene Language Specification 😛
10:41
Pete LeVasseur says:Knowing the bits that I know about safety-qualification (admittedly not as much as the group that made Ferrocene safety-qualified) I'd almost imagine that even after harmonization we'd probably want a mechanism to annotate what's required / useful to safety-qualification.
Assessors just will not care about certain things and it would be potentially a lot of additional work.
My 2c!
10:44
avatar
Mara Bos
Mara Bos says:👍
10:45
avatar
Josh Triplett
Josh Triplett says:👍
10:45
👍
10:51
me says:We can call both the spec. spec-machine-readable and spec-human-readable
10:52
PL
Pete LeVasseur
Pete LeVasseur says:Rust Qualification Specification? 😇
10:52
Type a message
> We can call both the spec. spec-machine-readable and spec-human-readable
Interesting thought. Despite assessors needing to read the document, my feeling is that yes the FLS was designed to be mechanically checked and produce useful artifacts to check for breakage downstream.
10:54
me says:I am ok with putting a qualifier in front of spec (for now), but I want to call something a spec.
10:54
Mara Bos
Mara Bos says:👍
10:57
Mara Bos says:the important thing for me is that the name does sound like we take it serious. "spec" or "qualification standard" or something seems fine. a meaningless acronym or something too specific minimizes its significance too much.
10:58
👍
10:59
me says:I am actually pretty down (in a good way) with "Rust Qualification Specfication" and "Rust Reference Specification"
11:00
I am actually pretty down (in a good way) with "Rust Qualification Specfication" and "Rust Reference Specification"
👍
11:00
avatar
Mara Bos
Mara Bos says:👍
11:01
PL
Pete LeVasseur
Pete LeVasseur says:Rust Reference Specification 🤝 Rust Qualification Specification
11:01
Mara Bos
Mara Bos says:👍
11:01
PL
Pete LeVasseur
Pete LeVasseur says:Agreed. Work Eric did on this matching can be cleaned up into some nice front-matter to make clear the purpose of each.
11:02
Josh Triplett
Josh Triplett says:> We should start working on a Rust specification.
11:05
Jack
Jack says:I am noticing that there are two of me
😂
11:13
PL
Pete LeVasseur
Pete LeVasseur says:FWIW -- generally speaking in the safety-critical community "standard" is viewed very authoritatively. Not trying to rabbit-hole, just some perspective.
11:14
J
Jack
Jack says:But, my thought here: the word specification *is* a word that has a connotation and I think its a cop-out to not properly act on that connotation
11:14
+1 on authority and "seriousness" - both of these align with the connotation
11:15
TC, I just want to be clear, that nobody is advocating calling the FLS "The Specification", which is why we are trying to compromise on the qualifiers for both documents.
11:19
*nobody is currently advocating, I should say.
11:20
I haven't thought about this enough yet, but it is possible that I would be open to calling the FLS "Rust Qualification Specification" and the Reference "Rust Specification"
11:23
The resourcing is a bit of a chicken and egg problem.
11:24
Thanks for joining today Mara.
11:24
avatar
Josh Triplett
Josh Triplett says:Three of a kind, will we get to four of a kind? 😃
😂
11:28
me says:Now there is three of you Jack lol
😂
11:28
avatar
Josh Triplett
Josh Triplett says:Rust Specification
- Rust Reference
- Rust Qualification Specification
11:31
me says:I am also happy to go the route of:
"Rust Qualification Specification"
"Rust Reference" (as it is named currently)
11:32
me says:But as TC said, if the Reference is the thing that is most like what a Rust spec should be, I believe it deserves to be attributed as such either with "Rust Specification" or "Rust Reference Specification"
11:33
Mara Bos
Mara Bos says:👍
11:37
Mara Bos says:👍
11:38
Sign in with Wallet
Connect another wallet