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

Attendees: Joel Marcey, Eric Huss, Pietro, Lukas Wirth, Felix Klock, Mara Bos, TC, Connor Horman

Potential Agenda:

* License Discussion
* Policy and Style
* Pietro discussion around libraries
* Testing
* Discuss Connor's sample chapter
* Choose more topics to write
* Any other business

## License Discussion

https://github.com/rust-lang/spec/pull/14

Eric: Any concerns with MIT/Apache?

Connor: Only concern is whether we should be applying a software license here.

Pietro: MIT/Apache allows for easier transitions between the Project code into the specification. Sharing between Project.

Eric: MIT is not a software only license

TC: MIT specifically includes documentation files.

Joel: We will have software with the specification - tooling, testing

Mara: We will be shipping this as one artificat, potentially with the compiler.

Joel: Many open source projects use MIT or Apache that include documentation

TC: MIT can provide additional guarantees that something like CC0 may not.

**Agreed that MIT/Apache will be used**

Pietro: Ferrocene license will be cleaned up so that its contents can be used within the specification

## Policy and Style

Eric: I'd also like to get started on working through policy and style issues. I think there will be a few dozen questions that we should probably decide sooner rather than later. Some will be small, like formatting or spelling considerations, but others might be more significant like the review process we would like to use. I can prepare a list of questions to get started, but I would like to know what would be the best way to answer and track those questions? Should we file individual issues or PRs for each one? How do we make decisions on those?

Felix: Conceding style questions to a smaller group of people within the team (Mara and Joel)

Joel: GitHub issues could be used to track these

Mara: Doesn't mind using GitHub issues

Eric: Will put open items into the GitHub Project.

Eric: Did Ferrocene have style guidelines or policies written down?

Lukas: Took inspiration from the Ada spec. Tried to have minimal forward jumps. Legailty words - like "shall". Two people. Lukas provided bullet points for content. The other editor actually wrote the specification.

TC: Thinking about how other parts of the project work, perhaps there should there be a contributing document or style guide in the repository. Maybe a small set of people would then provide PRs to it for the team to FCP or otherwise approve. Trying to delegate this to a subteam might raise challenging questions about how to define the scope of that delegation.

Eric: It's a good queestion. The process could slow down if we have a lot of FCPs for small decisions. On the other hand, these style questions could easily bleed out into broader questions.

Pietro: Could be easy to reverse decisions.

Connor: This seems like this could use Second, No objection process other teams use.

Joel: Would like to avoid adding unneeded process. All this work is going to be public anyway and anyone can provide feedback.

Mara: This is a different way of doing work than the rest of the project as we writing something big from scratch instead of small changes.

Pietro: We can let a small group here make decisions and if we don't like any of those decisions, we can of course raise concerns.

TC: If we delegate a scope of authority to a small group, it may be unwise, on a human level, to plan to often second-guess those decisions.

TC: For context, I raise this mostnly in the spirit of driving consistency between various teams in the project. But perhaps there's a reason to diverge here, and overall, I have no objections.

**Small delegation model to make decisions but can be informally verified and feedback provided**

Eric: Policy - what does the spec say about things like editions.

Mara: Library team hits merge for small, trivial changes.

## Libraries

Pietro: Better defining libcore is the next crucial item for Ferrocene. Still figuring out what that exactly looks like. ISO requirements. Question for spec team - what do we want? Ferrocene might be able to contribute time to actually work on this.

Joel: Is this work going to happen regardless of the direction of the specification?

Pietro: Yes. Ferrocene will have a deadline and the definition of libcore will need to be done by that deadline. But willing to upstream that work to the specification.

Joel: Theoretically, with the way we are structuring the writing, the library definition could be a black box that could be added to the specification. But what about following our style and policy?

Pietro: Agree. There needs to be alignment between what Ferrocene needs and what the specification needs.

Connor: Are we specifying the standard library?

Mara: Yes, but maybe not now. But if someone wants to work on it, then there is no need to wait.

Mara: For libcore, aligning style and formatting may not be the most interesting thing. It is actually defining the scope. If we can align what the scope is and if so, then having Ferrocene work on this should be fine because aligning style and formatting can be done pretty quickly.

Pietro: Those that would do the work would send PRs to the spec like everyone else. There is still a lot of planning on the Ferrocene side. But if there is tentative agreement that this is a good idea, then we can go off and define what the scope and requriements are. Then we can see if those are compatible.

Joel: In tentative agreement with this plan because of the extra resources that will allow us to get more efficient work in the specification.

Mara: Agree. We should try to make this collaboration.

Eric: Still unclear what this libcore chapter would be for? Why is there not more than just a link to the standard library.

Connor: If we have to do more normative work, then we do that within the specification or in the documentation and then link to the documentation. In either case, we need to specify library types that directly interact with the core language (in ways that regular rust code cannot) e.g. `Option`.

Mara: The other option is not having a specification document for libcore.

Joel: This is another good reason for the Ferrous proposal to come up with the requirements to see if we actually need to have libcore specified more than just links to the standard library.

Mara: Question for Ferrous - What about the existing libcore documention is not sufficient?

## Testing

Pietro: Are we going to have a test suite for each requirement in the specification.

Connor: Would like one

Mara: It would be nice to have

## Connor's Sample Chapter

https://github.com/rust-lang/spec/pull/15

Mara: Will look at chapter tomorrow.

Joel: Did you use extensions that Eric added for mdbook?

Connor: Yes and no. If we have rule name in there, it should be hidden away when using something other than our extended mdbook. A common comment I got when getting feedback outside the team is that the unformatted syntax was hard to read.

Eric: Leave it up to Mara and Joel to make decisions on what needs to be udpated.

Mara: How are we going to handle editorial decisions?

Joel: I can volunteer to do that.

Mara: Will also probably do that too :)

Connor: Editorial changes to fork by maintainers

Mara: Can also push to main after the fact.

Pietro: Recommend small policy - don't explictly put comments in PRs on just editorial changes.

## More topics

* Front Matter
   * Introduction
   * Specification Scope
   * Terms and Definitions
* Source code and Rust syntax tree (graph?) - T-lang
    * Lexing/tokenization
    * Grammar, AST
    * Crates, modules, source files
    * Macro invocations
    * Macro expansion and conditional compilation
    * Name/Path resolution of (mod-level) items
* Static semantics - mixed T-lang/T-types
    * type checking
    * associated item resolution
    * existential (impl Trait) resolution
    * borrow checking
    * unsafe checking
    * const eval - T-opsem?
    * type inference
* Dynamic Semantics - T-opsem
    * high level expression form
    * pattern matching and binding
    * dyn traits and dynamic method dispatch
    * memory layout and value representation
    * low level (MIR-like) statement form
    * memory model (borrowing; atomics)
    * ABIs and FFI linkage
* The Core library crate - T-libs-api
    * builtin types' traits and methods
    * core::* items
    * alloc

Connor: Dynamic Content

Mara: Lexing/Tokenizing (actually do need to think about macros)

Pietro: Libcore, potentially. Will get back to us

Joel: Not libcore anymore :). Will choose something else.

## Any other Business