T-spec meeting 2024-08-01

--- title: T-spec meeting 2024-08-01 tags: ["T-spec", "meeting", "minutes"] date: 2024-08-01 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-08-01 url: https://hackmd.io/WyCN3OOUT8yvS9tbQYD2Lg --- Attendees: Joel Marcey, Connor Horman, TC, Oli, Pierre-Emmanuel Patry, Mara, pnkfelix, Sid Askary, Urgau Minutes: TC Agenda: * Spec Glossary * Inline Assembly * ABI ## Spec Glossary https://github.com/rust-lang/reference/pull/1537 We discussed the issues that are raised in this PR. The team leaned toward preferring a more conversational tone for the specification.[^shall] We wanted to see where duplicate language actually came up in practice, and how often it did, before deciding to adopt new jargon. In the end, nobody on the team had concerns about closing the PR. If other glossary items come up, we can open new issues or PRs for those. [^shall]: As prior art, see e.g.: https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ ## Inline Assembly https://github.com/rust-lang/reference/pull/1550 We discussed the approach taken here. Specifically, we discussed how this does not preclude later more intrusive work on a chapter, it simply separates that out. We talked about preferring to do this reformatting first and as quickly as possible, and what the reasons for that are in terms of derisking the spec work and moving us toward our concrete goals to make it possible for the Reference to be adopted by safety-critical users. We talked about what is and is not in the critical path for that, and how we want to be sure to leave time for other things that are, such as associating tests with Reference material. We discussed what happens if we rename identifiers within a chapter. While the Reference preserves links to pages, i.e., if a page is deleted, a redirect is added, it has not historically (to the knowledge of anyone on the call) preserved links to fragments (i.e. headers, i.e. the things after the `#`) within pages. On that basis, we didn't seem to think it a problem to continue in that way for now, and if these fragments later need to be adjusted as we make other changes, that's fine. We could always later choose to make more stability guarantees on these fragments. Everyone seemed happy with the idea of doing these straightforward reformatting PRs first, and then doing other things later. Connor, in particular, was happy to have clarity here. ## ABI https://github.com/rust-lang/reference/pull/1545 We briefly discussed the ABI chapter, and in particular, we discussed the tradeoffs inherent in cases where the core library has substantial material that relates to guarantees made by the language. On the one hand, in a library-oriented language like Rust, it seems natural that some of these guarantees would live in the core library (e.g. with `UnsafeCell`), but on the other hand, it also seems natural for the specification to contain this language. The three options, of course, are to have this material in one place (and cross link the other), to have it in the other place, or to have it in both places. There seem to be pros and cons to each of these. The main concern with having it in both places is the trouble with keeping the material in sync, especially if it's rewritten separately in either place such that the copies are not byte-identical.