---
# System prepended metadata

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

---

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

Attendees: Joel Marcey, Mondiac Cat, Eric Huss, Mario Carneiro, Lukas Wirth, Connor Horman, TC, Pietro, pnkfelix

Potential Agenda:

* Representation and Validity Discussion
* GitHub Issue Triage
* Chapter Selection and Status

## Representation and Validity

[Context](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/representation.20and.20validity)

Connor: Ralf wants layout separate from representation

Mario: Also a disagreement about the use of the word "representation". The use here is not the same as used in the opsem discussions

Connor: Used the definition in the discussion so that could use the definition of type like did

Mario: opsem is going to be using minirust for this whole portion of the spec. Why isn't the prose version of the spec just using word for word minirust.

Connor: The wording doesn't need to be the same, just the meaning. But it needs to be adaptable.

Mario: minirust doesn't have a spec per se, but it does have structure. There should be a 1:1 correspondence with the spec and what minirust says.

Felix: How do we validate against minirust if we structure the content differently than how minirust describes it.

Felix: It is a good goal that minirust and the spec are consistent.

Connor: Manual validation?

Joel: That seems like a tough thing to do, possibly error prone.

Connor: Doesn't want to import SpecR

Mario: Most of the non-code minirust text is not normative.

Connor: doesn't think 1:1 correspondence is possible.

Felix: Impossible or not ideal?

Mario: It may be ok to have similar, duplicative information to the reader, for example on size

Joel: minirust is the default and we modify the spec as necessary

Mario: Can go both ways

Felix: A in minirust corresponds to A in the spec, 1:1, but it could also be A corresponding to A, B, C in the spec sometimes, 1:many

Mario: we should make it possible to have mostly a 1:1 mapping

Connor: 1 minirust concept should be covered by 1 chapter. Not necessarily a clause to line relation, but chapter to struct.

Mario: Can we prototype this? Compromise a literal translation of minirust to what can be a spec.

Joel: What is the downside of just going Connor's route?

Mario: Folks working on minirust will probably end up being unhappy. Want to get to a place where everyone is happy

Joel: Where do we go from here?

Mario: We start with an enumeration, for each thing we say about all values, one for each of them, text for each one of those cases, and then done.

Joel: Will there be a jarring difference between writing the spec the "minirust" way vs. other areas of the spec that may not be written that way?

Mario: We don't need to write the spec as code

Felix: WHy not start on text about values first? Why is that not a natural place to start?

Connor: Working based on time to take to complete. Value type could be months of work

Mario: Not convinced it will be months. Could be a day. Especially if you utilize what already exists in minirust.

Connor: Have background knowledge on layout and representation.

Mario: We want representations for every value. 

Connor: Just assume the minirust definition.

Mondiac Cat: [Minirust values definition](https://github.com/minirust/minirust/blob/master/spec/lang/values.md)

Felix: Me, Joel, and potentially Mara can work on this

## GitHub Issue Triage

[Issues to discuss](https://github.com/rust-lang/spec/issues?q=is%3Aopen+is%3Aissue+label%3A%22t-spec+meeting+discussion%22)

### Markdown Style Guideline

[Issue](https://github.com/rust-lang/spec/issues/40)

Connor: End of lines?

Eric: Use backslash to represent end of line.

TC: The "one sentence per line" style proposed is difficult for me to read, personally.  I always have to read the rendered version when the source is in this style.  And since sentences can still be long, I still need to turn on wrapping in my editor, and the result of that is very unpleasant.  This style feels like a workaround for poor tooling in the days before highlighted word diffs and highlighted side-by-side diffs.

Mario: One line per phrase? Line breaking on semantically important places.

Eric: Semantic linefeed is fine.

Joel: Linter for this or manual enforcement.

Eric: Can modify reference linter for this.

Mario: Phrase-based semantic line feeds look a bit like poetry.

TC: As with poetry, that can make it difficult to enforce a consistent style.  There seem to be three options: semantic (and/or phrase-based) line feeds, hard wrapping (e.g. at 80 characters), or soft wrapping (i.e. line per paragraph).

Pietro: Ferrocene wraps on 80 chars, but is not strictly enforced.

Lukas: Doesn't prefer wrapping at 80. Likes one sentence per line

Felix: In terms of workflows, I'm curious whether people spend more time reviewing rendered text, or spend more time looking at the source (which puts a strong value on the density of the text and raises the issues TC mentioned)?

Connor: source and rendered side by side

Joel: Same. But generally reviews source during GitHub reviews

Mario: Both semantic linefeed and 80 characters

Pietro: People mostly want to review the source code because of forking locally.

Mario: Can you just have a rule for suggested breaks? Just do something reasonable.

Felix: Can leave it up to the author, but some guidance is necessary

Eric: Make a proposal not to have line wrapping like TC was suggesting. Most of spec will be short clauses.

**Proposal**

**No line wrapping
Break on short clauses**

## Chapter Selection and Status

[Chapter Outline and assignments](https://github.com/rust-lang/spec/issues/43)

[Connor's chapter on Dynamic Layout](https://github.com/rust-lang/spec/pull/15)

Matthew Woodcraft [offered](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Lexing) to help with chapter on Lexing