T-spec meeting 2024-01-18

--- title: T-spec meeting 2024-01-18 tags: ["T-spec", "meeting", "minutes"] date: 2024-01-18 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-01-18 url: https://hackmd.io/O9YPNqivRx-SKWMQdp8Mww --- Attendees: Connor Horman, Lukas Wirth, Joel Marcey, Pietro, Eric Huss, pnkfelix, Mara, TC Potential discussion items: - Discuss spec sample chapter feedback - moving forward with spec format - future sample chapters - possible tooling ## sample chapter feedback Mara's presentation well received. limited feedback. Ralf probably responds on the weekend (if at all) Mara: should we put it on the agenda of the relevant teams? Felix to bring it up with the lang team. Connor to bring it up with opsem team. ## Tooling Mara: I'd like to write a tool that can produce my sample chapter. ## Processes Mara: processes for agreeing on things? we now have five versions of the array chapter, but all of them are different and slightly disagree. Who is going to review and how will we try to guarantee correctness? Felix: goal of the sample chapters wasn't correctness. Mara: true, but we will run into this soon when writing, so do we want to 'practice' how? Mara: example: definition of "slice", how do we decide? Joel: Can each chapter be mapped to a specific team? Mara: I think things like this should be decided by us, and we can always change things based on later reviews if necessary. asking lang team for every single term would take too much time. Eric: With the reference, we had a tiered structure where the author makes decisions, the reviewer works with them to refine it, and team decisions for things that are broader. and things that are unceartain within the team would go to the lang team. bubble things up based on how certain we are about things. Pietro: difference between lang FCP on the document, vs lang team members individually review Joel: different people will be interested in different topics, can review parts. Joel: small team of editors? mara, me, ? Mara: 2, 3? Joel: work on different chapters in parallel? Mara: No, bad idea. I'd like to work on the same chapter. E.g. joel writes the formal content, and I write the informal notes with the explanations. Forces me to review joel's output :) Eric: Different people writing different chapters will result in different voices. Problem with PRs to the reference from different people. Pietro: At ferrocene we had a non-technical editor who made sure things were in the same voice. Start with blank slate. Looks like there will be a lot of bikeshedding, try to avoid. E.g. take table of contents of reference. Mara: Bikeshedding definitely not worth the time in many cases, but e.g. structure (https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Common.20subclause.20structure/near/413018648) is very useful. ## Content Mara: Phases are useful for the spec, last phase being runtime. Connor: I identified six phases: lexing, parsing, macro expansion, semantic analysis, monomorphization, const eval. Did not include runtime or codegen. eric: https://github.com/rust-lang/reference/issues/916 is same issue for reference Felix: Should we collapse some of those? Which of these distinctions ends up mattering? Maybe that's what you meant connor, that these are observable to the user? Connor: yes. Felix: Basing it on diagnostics would be a mistake, but if this is based on behaviour, that matters. Mara: I think it's very important to start with identifying these phases. Other documents (Rust and non Rust) skip over this, implictly jumping back and forth between phases. Joel: Would we then have n/a sections if we use that structure? Mara: Don't care much if those phases are used as subsections everywhere, or just used to refer to from sentences. (E.g. "must be nonzero in phase 3") Connor: or keywords like "post-mono error". Mara: Exactly, we need those kind of terms. I needed those a lot while writing the small array sample. Pietro: How about runtime? Static vs dynamic behaviour? Mara: I like seeing runtime as just the last phase. Eric: careful about handling interpreter. don't overspecify such that it still makes sense for interpreting. Felix: Amanieu is working on something that skips monomorphization, for example. Connor: const blocks allow using generics in constant expression. Mara: Sounds like we're all in agreement that we should only specify the abstract phases that are absolutely necessary and nothing else. Checking if it still makes sense for an interpreter is a good test. Joel: Should we check this for arrays? Mara: for arrays for example, saying that the length must be an expression/const expression/non-zero const expression depends on the phase. didn't know how to specify that without wording for those phases. Pietro: we could define "const expression" in one place what that means for the different phases. Pietro: depends on the end user which details you want to go into. Mara: example with `m!($x:ty)`m, is `m!([[u8]; 1])` legal? We say that the type in `[T; N]` must be sized, but `[u8]` is not sized. But that's a requirement for a later phase. We should document that explicitly, instead of implicitly having rules apply to different phases. Eric: So do we want to use this as words to refer to in the text, or do we want to have explicit sections for each phase, or .. ? Mara: I don't know. I think as our homework we should play a bit with things to see in which ways the phases will be relevant. Eric: Agree that the phases are very important. Joel: Agree we should play with the phases model. Eric: Phases imply linearity. we should be careful with that. Mara: The C++ standard defines a bunch of phases that don't match the implementations. It's fine if the phases are abstract. Pietro: minimizing the phases as much as possible is good, but it's easier to merge phases than to split them, so might want to start with more than necessary. ## Action items - Feedback from lang (felix) - Feedback from opsem (connor) - Form an understanding of the abstract phases (joel and mara, with help of connor) - Bootstrap tooling (mara)