---
title: T-spec meeting 2024-02-20
tags: ["T-spec", "meeting", "minutes"]
date: 2024-02-20
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Top-level.20chapters.20meeting
url: https://hackmd.io/gqNmzYyKRD-slKYSidwrsA
---

Attendees: Joel Marcey, Eric Huss, Lukas Wirth, Mara Bos, pnkfelix

## Potential Agenda

- What are the top level specification chapters?
- Any other business

## What are the top level specification chapters?

### Brainstorm, topics that need a place somewhere:

Introduction
Specification Scope
Terms and Definitions

Tokenization
Grammar
* Source input: lexing and grammar for original source code itself
AST
Macros
* macro definition form(s)
* macro-by-example
* procedural macros
* hygiene
* macro invocation
* invoke!(...)
* #![invoke]
* #[derive(Invoke)]
* #[cfg()] ?
* Core grammar post expansion

Name Resolution, namespaces
Module system
* crates
* module tree
* use imports; path structure (possibly needs combination with name resolution above)
Static Type Structure
* generics
* lifetimes? variance + subtyping?
* binding and scope of generic parameters
Unsafe
* unsafe fn's, unsafe operators, unsafe blocks, and safety checking
* The rust safety promise: safe Rust doesn't cause UB.
Functions
* Procedure + method definition
Expressions
Pattern structure
Control flow
* pattern matching, and binding
Temporaries (lifetime, and extension)
`#[repr(..)]`
ADS: structs, enums, unions, etc.

Atomic Memory Model
(non-atomic?) Memory Model
Data Representation and Memory Layout

Traits
* associated items
Trait impls
Trait resolution
* pnkfelix Q: this stands for resolution the impl when given the (Type,Trait) pair, yes?
* Or is it more general (e.g. resolving the associated item when given the receiver type and the associated item's symbolic name)
Existential trait (impl Trait) resolution
Trait bounds
FFI
libcore
FFI/extern/linking
inline assembly

Type Inference and Checking
Borrow checking

Error Handling (?)
Operators

Static semantics:
- type checking
- safety checking
- borrow checking

### Very high level structure so far:

- Front Matter
- Introduction
- Specification Scope
- Terms and Definitions
- source.. something.. ?
- grammar, ast, macro invocations
- declarations/definitions
- bodies/expressions, operator precedence, etc.
- ...
- modules, interaction with file system
- macros and conditional compilation
- macro definitions
- macro expansion
- `#[cfg]`
- name resolution
- part 1: just paths into modules, for macros
- part 2: with traits, fn params, let-bound names, etc.
- or global vs local?
- defining.. items .. ?
- module paths, ..
- importing crates, ..
- visibility, pub/private, etc.
- name resolution
- hygiene
- macros 1.0 vs 2.0
- ...
- types (traits, types, resolution)
- borrow checking
- functions
- const/static/...
- expressions and control flow (stuff in function bodies, basically)
- temporaries
- patterns
- match exhaustiveness
- borrow checking
- type inferrence
- opsem (based on MIR?) (not mir, but something where while/for/loop etc. are no longer relevant, for example)
- memory model (atomic, non-atomic)
- memory layout/representation (Option, repr(), NonNull, ...)
- undefined behaviour
- ABI, FFI.. ?
- ..
- const eval
- .. ?
- core library
- traits and methods of builtin types
- core::*
- unsafety??
- ... ?

## Any other business

Will we have one top-level chapeter for types and one top-level chapter in opsem?

- Send a message to lang, opsem, types asking them what chapters they would like to see in the specification?
- Can see if they match what we are thinking