---
# System prepended metadata

title: T-spec meeting 2024-12-12
tags: [T-spec, meeting, minutes]

---

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

Attendees: Joel Marcey (for 30 minutes only), Niko Matsakis, TC, Eric Huss, Pierre-Emmanuel Patry, Connor Horman, Monadic Cat

Regrets:

Agenda

- Formal Specification Appendicies
- Meeting Efficiency
- Review Questions

## Formal Specifiation Appendicies

https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/.22Formal.20Specification.22.20appendices.3F

Joel: Curious what does Eric think since this will affect the reference.

TC: Same

Eric: Dedicated parsing chapter in the current flow, instead of a dedicated appendix. For the Reference, just make changes instead of making appendices since there is already content for these things.

Joel: Would appendicies be non-normative?

TC: Some can be normative.

Connor: Yes

Eric: Yes, C++ has both.

Niko: A version of a chapter documenting nightly content (??).

Eric: Async closures touch six different chapters. Tough to make that independent.

Niko: Value in having an appendix in new content that is in progress that will at some point replace current content.

TC: What is the status of unstable book?

Niko: Probably I'm thinking of something more normative than that.  This is where I've had in mind updating the RFCs after the fact.

TC: As we've already seen, we're going to get pushback on that, and for good reasons.  Maybe what we could do instead is to take the relevant sections from the RFCs that we're stabilizing, update them, and then put them somewhere else.  It could be as a separate book, or perhaps as an appendix to the Reference.

Niko: That'd be a good way to include motivation and design goals.

**TC: I could see a workflow where people would open a PR that adds an appendix with the "guide level" and "reference level" content and *also* makes the changes throughout the Reference.  Then, when we're reviewing it, we'll have in front of us both the self-standing explanation and the intrusive changes that can be cross-referenced.**

NM: I like it.

Joel: What exactly is our response to Matthew?

TC/Joel: Acknowledge that there will be a process of integrating Matthew's work, but we will potentially use appendicies in a different way.

Joel: I will respond to Matthew

## Meeting Efficiency

Joel: How can we make this meeting more efficient? Capturing agenda items? All that stuff.

nikomatsakis: I've been wondering the same, is an hour really needed was on my mind.

Joel: Is lang team triage an hour?

Niko: Yes.

Niko: Can topic timers work?

Joel: I have tried subtly but doesn't always work.

Niko: Half stuff can be done online, other async.

TC: It can be hard to cut off a topic because finishing it and disposing of the matter can be on net more efficient than having to pick it back up later and essentially repeat much of the same discussion.

Niko: There's that, and also I've realized that talking through these items is how we calibrate as a team and build a shared understanding and shared values.  Maybe only half of the discussions are important for this, but it can be hard to tell in the moment whether or not a particular item is in this category.

TC: Yes.  That's also become apparent to me in doing Reference reviews with Eric.  We've become far more calibrated and synchronized by doing those.  And so, similarly here, I wonder whether there might be value in using the time on the spec calls to do operational work -- like lang does in triage -- to go through review items.  There's essentially an infinite amount of this work to do, and beyond getting the work done, it will also help us to calibrate as a team.

Niko/ehuss/Joel: +1.

All: Sounds like a plan for the new year.

## Next meeting?

Joel: Do we want to meet either next week or on the 26th?

All: No.  We'll see everyone again in 2025.

## Review questions (ehuss)

- Async closure (`Async*` family impl, final review) https://github.com/rust-lang/reference/pull/1692
- `do_not_recommend` final review https://github.com/rust-lang/reference/pull/1663
- `coverage` https://github.com/rust-lang/reference/pull/1628, don't know where this is on the lang radar

## Chat

nikomatsakis
nikomatsakis says:"conflicted" 
8:13
nikomatsakis says:I kind of need to drop today too, but I'm game to start this new approach in the new year.  (I think we are not meeting next week?) 
8:26
nikomatsakis says:SEE. 
8:26
👋 
8:28
MC
Monadic Cat
Monadic Cat says:lol 
8:28
me says:Happy Holidays, everyone! 
8:29
me says:Love the snow in HackMD 
8:29