---
# System prepended metadata

title: T-spec meeting 2024-02-20
tags: [T-spec, meeting, minutes]

---

---
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

