Types — record, sum-type, protocol, generic, поля

Решения этой группы задают систему типов Nova: четыре формы объявления данных, структурные контракты-протоколы, семантику передачи параметров и мутабельность полей, делегацию через use. Синтаксические детали (методы через @, generic-применение [T], литералы) — в 03-syntax.md.

D17. Объявление типов: единый синтаксис без |

⚠️ REVISED. Заменено D52. Старый синтаксис (type X = Y для alias, type X = A, B для sum) — запрещён. Новый: type X Y (newtype), type X alias Y (alias), type X | A | B (sum). Текст ниже — для исторической справки.

Что

Все формы объявления типа — record, позиционная структура, unit, alias, sum-type — используют один разделитель списка (запятая) и синхронизированы по =: = ставится только когда справа выражение типа (alias или sum-type), не когда форма данных ({...} или (...)).

Правило

Полный синтаксис:

// alias
type UserId = u64

// record (именованные поля)
type User { id u64, name str }

// позиционная структура
type Point(f64, f64)

// unit-тип (без полей)
type Empty

// sum-type
type Color = Red, Green, Blue

type Shape =
    Circle { radius f64 },
    Square { side f64 },
    Triangle { a f64, b f64, c f64 }

type Result[T, E] = Ok(T), Err(E)

Парсер однозначен по первому токену после имени типа:

type X { ... } — это record с полями. Методы внутри {...} запрещены: набор методов = поведение, для него используется protocol (D42). Эффекты — это protocol, использованный в позиции эффекта между ) и -> (04-effects.md → D18).

Создание значений и pattern matching — обычные:

ro p = Point(1.0, 2.0)
ro u = User { id: 1, name: "alice" }
ro c = Circle { radius: 5.0 }

match shape {
    Circle { radius }    => 3.14159 * radius * radius
    Square { side }      => side * side
    Triangle { a, b, c } => heron(a, b, c)
}

Field punning для record-литералов: если имя поля совпадает с именем переменной в скоупе, можно писать имя один раз:

ro key = "alice"
ro value = 42

ro entry = Entry { key, value }                    // shorthand
ro entry = Entry { key, value, extra: "data" }     // можно смешивать

Парсер однозначен: name: → полная форма, name, или name} → shorthand. Если переменной нет в scope — compile error.

Partial pattern matching — две эквивалентные формы:

// явная — с маркером ..
match @buckets[idx] {
    Occupied { value, .. } => Some(value)
    _                      => None
}

// неявная — без маркера, остальные поля игнорируются
match @buckets[idx] {
    Occupied { value } => Some(value)
    _                  => None
}

Явная форма — visual cue «здесь ещё поля». Неявная — краткость.

Переименование при деструктуризации остаётся явным: Occupied { key: k, value }.

Construction всегда требует все обязательные поля — частичное заполнение типа Rust ..default отдельным синтаксисом не зафиксировано.

Почему

1. Один разделитель списка на весь язык — запятая. Параметры, элементы массивов, поля записи, варианты sum-type — везде ,. Меньше правил, меньше ошибок LLM.
2. = означает «справа выражение типа». Когда справа форма данных — = лишний.
3. Парсер по первому токену — никакого backtracking, чистые сообщения об ошибках.

Что отвергнуто

• ML-style | Variant (OCaml/Haskell/F#/Rust). Два разделителя подряд (= |), чужд языкам не из ML-семейства, дублирует роль запятой.
• type Point = | Point(f64, f64) для одно-вариантного sum-type — дубль. Sum-type с одним вариантом и структура — это одно и то же.
• type User = { id u64, name str } для record. = лишний, когда справа форма данных.

Связь

• 03-syntax.md → D27 — массивы ([]T, [N]T) как отдельные конструкции типов, не варианты type.
• 03-syntax.md → D38 — generic-применение Имя[T] для параметризованных типов.
• 02-types.md → D42 — почему protocol отдельный keyword, а не type X = { методы }.
• 02-types.md → D36 — префиксы полей (readonly, mut) и group-syntax внутри record.

D52. Объявление типов revised: newtype, alias, sum через leading |

⚠️ REVISED. Синтаксис sum-type заменён D406: enum Variant | ... вместо leading | Variant | .... Остальные формы (newtype, alias, record, tuple, unit) без изменений.

Что

Полная пересборка D17. Один keyword type для всех data-форм, никаких = в декларациях, форма различается первым токеном после имени. Шесть форм:

• newtype — type X Y (X — новый тип, типизированно отличный от Y, Go-style)
• alias — type X alias Y (X и Y совместимы, для длинных дженериков)
• record — type X { поля } — heap-allocated reference type (GC-managed)
• tuple — type X(типы) — stack-allocated value type (позиционные поля .0/.1)
• named tuple — type X(name1 T1, name2 T2) — stack-allocated value type (именованные поля .name) (D215, Plan 120)
• unit — type X (ничего после имени)
• sum — type X enum A | B | C (enum маркер обязателен; D406)

Allocation contract (D215, Plan 120): скобки кодируют семантику размещения: () = stack-allocated value type, copy-семантика при передаче; {} = heap-allocated reference type, GC-tracked. Выбор формы явно документирует производительность и lifetime ожидания.

Sum-варианты могут иметь числовые discriminants с auto-increment. protocol остаётся отдельным keyword’ом для поведения (D42).

Правило

Полный синтаксис

// 1. Newtype — type X Y, без =
type UserId u64
type Email str
type Score f64

// 2. Alias — type X alias Y, для сокращения длинных дженериков
type StringMap[V] alias HashMap[str, V]
type Cache[K, V] alias HashMap[K, (V, Time)]

// 3. Record — type X { поля }
type User { id u64, name str }
type Point3D { x, y, z f64 }                    // group-syntax (D36)
type Account {
    ro id u64
    balance money
    mut last_access time
}

// 4a. Positional tuple — type X(типы)
type Point(f32, f32)          // .0 / .1 access
type Pair[A, B](A, B)

// 4b. Named tuple — type X(name type, ...) (D215, Plan 120)
type Vec3(x f64, y f64, z f64)       // .x / .y / .z access; stack-allocated
type Color(r u8, g u8, b u8, a u8)
type Generic[T](value T, count int)

// 5. Unit — type X
type Empty
type Sentinel

// 6. Sum — type X enum A | B (enum маркер обязателен; D406)
type Color enum Red | Green | Blue
type Direction enum North | East | South | West

// Sum многострочный — если варианты на новых строках, | обязателен у каждого
type Result[T, E] enum
    | Ok(T)
    | Err(E)

type Shape enum
    | Circle { radius f64 }
    | Square { side f64 }
    | Triangle { a f64, b f64, c f64 }

Парсер однозначен по первому токену после имени (с учётом дженериков)

Парсер видит первый токен — сразу знает форму. Для ( — один дополнительный lookahead: если (IDENT type → named tuple, иначе → positional tuple. Никакого backtracking.

Модификаторы type-declaration

Помимо kind-токена, type-declaration может нести модификаторы — они не меняют «форму» типа, а добавляют квалификаторы:

priv(file) — двойная позиция: prefix перед type (priv(file) type X { … }) или modifier после имени (type X priv(file) { … }). Обе формы эквивалентны. Для fn и const только prefix-форма: priv(file) fn f(), priv(file) const K.

Грамматика type-declaration: [export] type Name[T] [value] [priv|priv(type)|priv(file)] [consume] { … } эквивалентно: [export|priv(file)] type Name[T] [value] [priv|priv(type)] [consume] { … }

Модификаторы комбинируются: export type Job value priv consume { … }.

Поля внутри {…} могут иметь field-level модификаторы: ro (D175), mut (D36), priv / priv(type) / priv(file) (D281/D307).

Sum-варианты с числовыми discriminants

// Auto-increment без явных значений (от 0)
type ExitStatus enum Ok | Failure | Critical                  // 0, 1, 2

// Auto-increment от заданного
type FileMode enum Read = 1 | Write | Execute                 // 1, 2, 3

// Все явные
type ErrorCode enum
    | NotFound       = 404
    | Unauthorized   = 401
    | InternalError  = 500

// С отрицательными
type Sign enum Negative = -1 | Zero = 0 | Positive = 1

// Decreasing/non-monotonic — разрешено
type Code enum A = 10 | B = 5 | C                            // A=10, B=5, C=6

// Явный базовый тип
type Bit u8 enum Off = 0 | On = 1
type HttpCode i32 enum Ok = 200 | NotFound = 404

⚠ Явный базовый тип пока не реализован (parser drift, 2026-05-27). Формы с u8/i32/etc. между именем и enum парсер отвергает. Работает только дефолтная форма (без базового типа, implicit int). См. Plan 105.

Правила discriminants:

1. Базовый тип — дефолт int. Опционально явный (type X i32 enum, type X u8 enum).
2. Auto-increment от первого варианта:
   • Первый без значения → 0.
   • Каждый следующий без значения → предыдущий + 1.
3. Отрицательные значения — разрешены.
4. Decreasing/non-monotonic последовательности — разрешены.
5. Конфликт значений (два варианта с одинаковым discriminant) — запрещён компилятором.
6. Mixed (некоторые с полями, некоторые без, у всех discriminants) — разрешено:

   type Event enum
       | Click(x int, y int)              = 1
       | KeyPress(key str)                 = 2
       | Idle                              = 3
       | Data { payload []u8, crc u32 } = 10
   

Cast между sum-типом и числом

Sum → int — безопасный, всегда работает:

ro c = Red                 // Color
ro n = c as int            // 0 (если auto-increment)

ro e = NotFound            // ErrorCode
ro n = e as i32            // 404

int → Sum — через pattern match obligation:

ro n = read_from_db()
ro c = match n {
    0 => Red
    1 => Green
    2 => Blue
    _ => throw InvalidColor
}

Никакого n as Color — программист сам обрабатывает «нет такого варианта». Это согласовано с эффектом Fail[E].

stdlib может предоставлять Color.from_int(n) для удобства:

fn Color.from_int(n int) Fail[InvalidVariant] -> Color =>
    match n {
        0 => Ok(Red)
        1 => Ok(Green)
        2 => Ok(Blue)
        _ => Err(InvalidVariant)
    }

Параметризованные sum

type Option[T] enum Some(T) | None
type Result[T, E] enum Ok(T) | Err(E)
type Tree[T] enum
    | Leaf
    | Node { value T, left Tree[T], right Tree[T] }

Параметры в [...] после имени работают везде, как и раньше.

Сравнение alias и newtype

type AliasUserId alias u64
type NewUserId u64

ro a AliasUserId = 42        // ok
ro b u64 = a                  // ok — alias совместим с u64
ro c u64 = 42
ro d AliasUserId = c          // ok — обратное тоже работает

ro n NewUserId = 42           // ok (литерал подгоняется под целевой тип)
ro e u64 = n                  // ОШИБКА: NewUserId не u64
ro f u64 = n as u64           // ok через cast

Альтернативу newtype через record-обёртку (type X { value u64 }) никто не запрещает, но type X u64 — компактнее и привычнее программистам с фоном Go.

Field punning — расширено и обязательно

D52 расширяет field punning из D17 двумя правилами:

1. Shorthand для @field-доступов (новое в D52):

type RangeIter { end int, inclusive bool, mut cur int }

fn Range @iter() -> RangeIter =>
    { @end, @inclusive, cur: @start }
//    ↑    ↑           ↑
//    @end shorthand   полная форма (имя поля cur ≠ start)

{ @end } означает «поле end, значение @end (то есть self.end)». По симметрии с D17 ({ name } для переменной name в scope) — теперь { @field } для self-доступа.

2. Shorthand обязателен, когда имя поля совпадает с источником:

// Переменная в scope:
ro key = "alice"
ro value = 42
ro entry = Entry { key, value }                  // ✓ обязательная форма
ro entry = Entry { key: key, value: value }      // ✗ ОШИБКА: избыточная форма

// @field-доступ:
ro r = { @end, @inclusive, cur: @start }         // ✓
ro r = { end: @end, inclusive: @inclusive, ... } // ✗ ОШИБКА: избыточная

// Явная форма обязательна, когда имя источника отличается:
ro entry = Entry { name: user_name }             // ✓ имя поля ≠ переменной
ro r = { cur: @start }                            // ✓ имя поля cur ≠ start
ro r = { end: other.end }                         // ✓ источник — выражение, не @field

Парсер: { name/{ @name/{ name,/{ name } — shorthand; { name: expr — полная форма. После : ожидается выражение, но если выражение — это ровно тот же identifier или @+identifier, что и имя поля → ошибка компиляции «избыточная форма, используйте shorthand».

Status: ✅ enforced (2026-05-17, commit 34666922c35). Реализация в compiler-codegen/src/types/mod.rs RecordLit walker. AST flag RecordLitField.at_shorthand различает parser-generated @field shorthand от explicit { field: @field } (одинаковая AST форма). Test guards: nova_tests/negative_capability/d52_redundant_field_literal_rejected.nv

• d52_redundant_self_field_rejected.nv.

Mixed разрешён:

{ @end, @inclusive, cur: @start, kind: "iter" }     // shorthand + полные

Когда расширение работает:

Pattern matching и construction

match @buckets[idx] {
    Occupied { value, .. } => Some(value)            // partial с ..
    Occupied { value }     => Some(value)            // partial без ..
    _                      => None
}

Construction всегда требует все обязательные поля. Частичное заполнение типа Rust ..default отдельным синтаксисом не зафиксировано.

Что запрещено

• type X = Y для alias — старый D17 синтаксис, заменён на type X alias Y.
• type X = A, B для sum — заменён на type X enum A | B.
• type X = { ... } для record — синтаксис никогда не был активным (D17 уже отвергал), = в этой позиции запрещён.
• , для разделения вариантов sum — заменено на |.
• Sum без enum маркера — запрещён (type X Red | Green ✗, type X enum Red | Green ✓). См. D406.
• Single-variant sum — запрещён (как в D17), используйте record.
• Конфликт discriminants — запрещён.
• Избыточная форма { name: name } — обязателен shorthand { name }. Аналогично { field: @field } — обязателен { @field }. Если имя источника совпадает с именем поля, программист обязан использовать shorthand. См. «Field punning» выше.

Почему

1. Системность. В D17 правило «= для выражений типа, без = для форм данных» работало для alias, но спотыкалось на sum-type: type Color = Red, Green, Blue — справа не «выражение типа» в обычном смысле, а список конструкторов. С D52 sum обрабатывается как именованная форма (через |), как и record/tuple/unit.
2. Никаких = в декларациях типов — устраняется напряжение «иногда есть, иногда нет». = остаётся за binding’ом значений (let x = ...) и parameter defaults (если будут).
3. Newtype как first-class. Domain-modeling (type Email str, type Score f64) даёт реальную защиту типов без шумной record-обёртки. Прецедент Go (type UserId int64).
4. Discriminants для wire-протоколов. HTTP-коды, syscall-коды, serialization tags — программист может задать стабильные значения, как в C/TS/Swift enum.
5. Парсер однозначен по первому токену — никакого lookahead глубже одного-двух токенов. AI-friendly: LLM с одного взгляда понимает форму.
6. Leading | для sum — visual symmetry: все варианты выровнены, прецедент OCaml/F#/Scala 3.
7. Согласованность с D1 «protocols + data, без классов» — type только для данных, protocol отдельно для поведения.
8. Field punning расширен и обязателен. Один способ записать «поле = источник с тем же именем» — shorthand. Запрет избыточной формы { name: name } устраняет «два пути к одному результату», что AI-unfriendly (LLM генерирует случайно). Также покрывает { @field } для self-доступов — частый паттерн в record-литералах методов-конструкторов. Прецедент: TS/Rust имеют shorthand, но не делают его обязательным; Nova идёт строже ради единого стиля (D40/D43-стилевая последовательность).

Что отвергнуто

• Сохранить type X = Y для alias. Создаёт асимметрию: alias и sum с =, record/tuple/newtype без — нет единого правила.
• Kind-токен enum с фигурными скобками (type X enum { A, B }). Заменено на type X enum A | B без скобок (D406).
• Литералы как sum-варианты (type State | "open" | "closed", TS-style literal types). Полезно, но это отдельная фича (subtyping, runtime representation), отложена на следующую версию языка.
• Итерация по вариантам (for c in Color). Связано с reflection и stdlib, отложено до Q9.
• type X protocol { ... } под единым type. Семантически protocol — поведение, не данные; отдельный keyword чище.
• type X newtype Y с явным kind-токеном. type X Y без токена короче и согласовано с Go.
• Implicit cast int → Sum. Type-небезопасно (число может не попасть в варианты). Только через pattern match.

Цена

1. Большой breaking change. Все существующие декларации в spec/, decisions/, examples/ переписать. Кода пока мало, миграция разовая.
2. alias становится keyword’ом. Раньше был обычным идентификатором.
3. Программистам с фоном Rust/TypeScript: type X = Y больше не alias, а ошибка. Адаптация через документацию.
4. Парсинг type X Y (newtype) vs type X (unit) — различие по следующему токену (тип vs конец строки). Просто, но требует внимательности.
5. | имеет двойную роль — разделитель в sum и @or в операторах (D46). Парсер различает по контексту.

Связь

• D17 — старая версия, помечена revised → D52.
• D42 — protocol остаётся отдельным keyword’ом для поведения.
• D36 — префиксы полей (readonly, mut) и group-syntax внутри record.
• D39 — delegation через use Type. Newtype с embed (type X { use Y }) — альтернатива alias для случаев, когда нужна обёртка с дополнительными полями.
• 03-syntax.md → D44 — числовые литералы (0xFF, 1_000, негативные) — используются для discriminants.
• 03-syntax.md → D46 — | в operator overloading (@or) — разрешается компилятором по контексту. Полная семантика overloading — D84.

Открытые вопросы

• Литералы как sum-варианты (TS-style | "open" | "closed") — отложено до следующей версии.
• Итерация по вариантам (for c in Color, Color.values()) — связано с reflection, откладывается до Q9 (stdlib).
• Implicit cast литерала в newtype. Сейчас let u UserId = 42 — допустим (литерал подгоняется), но let n u64 = 42; let u UserId = n — требует явного cast. Точную семантику зафиксировать в Q (литералы vs binding’и).

Эволюция

D17 был первой итерацией, основанной на правиле «= для выражений типа». Со временем выяснилось, что:

1. Sum-type с = — натяжка («справа выражение типа» не точно описывает список вариантов).
2. Newtype отсутствовал как явная фича — программистам приходилось делать record-обёртки type X { value u64 }, что шумно.
3. Discriminants на sum-вариантах не были специфицированы — но реальные wire-протоколы их требуют.

D52 решает все три, ценой breaking change по syntax-site всех type-объявлений. Подробно — history/evolution.md.

D406. Sum-type синтаксис: enum маркер (2026-07-01)

Revises D52 §«Sum». Остальные формы D52 (newtype, alias, record, tuple, unit) без изменений.

Что

Sum-type теперь объявляется с обязательным ключевым словом enum вместо leading |. Keyword enum — маркер в грамматике типов, поэтому он работает везде где допустим тип: в named-type declaration, в позиции параметра, возврата, поля, binding’а.

Правило

Синтаксис

// Named sum inline — без | перед первым вариантом
type Color enum Red | Green | Blue
type Direction enum North | East | South | West
type Option[T] enum Some(T) | None

// Многострочный — | обязателен у каждого варианта (включая первый)
type Result[T, E] enum
    | Ok(T)
    | Err(E)

type Shape enum
    | Circle { radius f64 }
    | Square { side f64 }
    | Triangle { a f64, b f64, c f64 }

// С discriminants
type ExitCode enum Ok = 0 | Failure = 1 | Critical = 2

// С явным базовым типом (пока не реализован, Plan 105)
type Bit u8 enum Off = 0 | On = 1

Inline enum в type-позиции

enum Variant1 | Variant2 — это тип-выражение, валидное в любой позиции где допустим тип:

// Параметр функции
fn job(a enum A | B) { ... }

// Возвратный тип
fn parse() -> enum Ok(int) | Err(str) { ... }

// Поле записи
type Response {
    status enum Ok | NotFound | InternalError
}

// Let-binding
ro x: enum Some(int) | None = Some(42)

type Foo enum A | B — это объявление имени для типа-выражения enum A | B. Named и inline — одна грамматика.

Минимум один вариант.

| в inline и многострочной формах

• Inline — | разделяет варианты, перед первым не нужен: type Color enum Red | Green | Blue
• Многострочный — если варианты на новых строках, | обязателен у каждого варианта (включая первый), аналогично type-set bounds:

type Color enum Red | Green | Blue       // inline — без | перед первым

type Result[T, E] enum                   // многострочный — | обязателен
    | Ok(T)
    | Err(E)

Парсер

В type-expression position enum — prefix, парсер строит EnumTypeExpr.

Почему

1. Симметрия с alias. type X alias Y и type X enum A | B — одна структура: keyword даёт форму, далее описание. Единый паттерн.
2. Явный grep-маркер. enum в любой type-позиции мгновенно идентифицирует sum-type — в IDE, grep, LLM-prompt.
3. Устраняет неоднозначность |. В D52 leading | конфликтовало с оператором @or и вызывало удивление. enum — незвуковой маркер без операторных коннотаций.
4. Inline enum. Анонимные sum-типы в позициях параметра/возврата/поля становятся возможными — естественный extension грамматики.
5. Named = type + inline. type Foo enum A | B тавтологично читается: «тип Foo это enum A или B». Интуитивно.

Что отвергнуто

• Сохранить leading | (D52). Конфликт с оператором; не grep-абелен; inline-позиция невозможна.
• enum { A, B } со скобками (Go/C стиль). Нарушает Nova-правило «{ → record»; , как разделитель заменено на | ещё в D52.
• sum A | B (другой keyword). enum общепринятый термин в PL; sum слишком математичен, непривычен программистам.
• type X = enum A | B с =. Убрано ещё в D52; D406 следует тому же принципу «никаких = в type-declaration».

Связь

• D52 — заменяемый синтаксис
• D53 — protocol/effect kind-токены в той же системе
• D310 — set kind-токен в той же системе; | в type-set тоже разделитель, не оператор
• D55 — literal coercion в позиции sum-type (inline enum тоже)
• 03-syntax.md → D46 — | как @or оператор — разрешается по контексту (keyword enum/set или expr-контекст)
• Plan 105 — явный базовый тип discriminants

D53. Унификация: protocol под type, protocol как kind-токен

Что

protocol перестаёт быть отдельным keyword’ом. Становится kind- токеном в системе D52, наряду с alias. Все объявления типов (включая структурные контракты-protocol’ы) идут через единый keyword type. Анонимный protocol-тип в позиции параметра пишется через protocol { ... } (с явным маркером, симметрично []T, (A, B), fn() -> T).

any — пустой именованный protocol-тип в prelude:

type any protocol { }

Правило

Объявление через type X protocol { ... }

// Раньше (D42): отдельный keyword
protocol Hash {
    hash() -> u64
    eq(other Self) -> bool
}

// Теперь (D53): kind-токен в системе D52
type Hash protocol {
    hash() -> u64
    eq(other Self) -> bool
}

type Logger effect {
    log(msg str) -> ()
}

type Iterator[T] protocol {
    next() -> Option[T]
}

type Db effect {
    query(q Sql) Fail[DbError] -> []DbRow
    exec(q Sql)  Fail[DbError] -> int
}

Парсер: protocol как kind-токен после имени

Расширение таблицы D52:

protocol, effect, enum, set, alias, value — kind-токены после имени. Парсер однозначен по первому токену после имени (или generic-параметров).

Анонимный protocol-тип в позиции параметра

protocol { ... } в позиции типа — анонимный protocol-литерал, симметрично []T, (A, B), fn() -> T:

fn log_one(x protocol { show() -> str }) Log -> () =>
    Log.info(x.show())

fn closer_call(c protocol { close() -> () }) Io -> () =>
    c.close()

fn process(x any) -> () =>      // any — именованный пустой protocol
    ...

fn process2(x protocol { }) -> () =>   // эквивалент через анонимный
    ...

Маркер protocol обязателен — { ... } без префикса в позиции типа запрещено. Это убирает двусмысленность с record-литералами и выражениями-блоками.

any в prelude

// В prelude:
type any protocol { }

Любой тип удовлетворяет пустому контракту (структурная типизация), поэтому any — top-type. Использование:

type Logger effect {
    log_event(level int, fields []any) -> ()
    //                          ^^^^^ массив значений любого типа
}

fn dump(x any) Io -> () =>
    println(x)

Имя any lowercase — исключение в D30 naming convention, по аналогии с примитивами (int, str, bool, f64, ()). Top-type концептуально близок к примитивам — встроенный универсальный тип.

Эффекты — без изменений

Эффект — это protocol-тип, использованный в позиции эффекта (между ) и ->). Меняется только синтаксис объявления, не использования:

type Db effect {
    query(q Sql) Fail[DbError] -> []DbRow
    exec(q Sql)  Fail[DbError] -> int
}

fn list_users() Db -> []User =>      // Db в позиции эффекта — как раньше
    Db.query(sql`SELECT * FROM users`)

Generic-параметры — без изменений

D42-уточнение про две модели (на protocol-уровне и на методе) сохраняется. Меняется только синтаксис объявления:

// Модель A — generic на protocol
type Container[T] protocol {
    add(item T) -> ()
    get(idx int) -> T
}

// Модель B — generic на методе
type Tracer effect {
    span[T](body fn() -> T) -> T
    measure[U](body fn() -> U) -> Duration
}

Структурная совместимость — без изменений

Любой тип со структурно совпадающими методами автоматически удовлетворяет protocol’у:

type User { id u64, name str }

type Display protocol {
    show() -> str
}

fn User @show() -> str => "User(${@name})"

fn log_one(x Display) Log -> () =>
    Log.info(x.show())

log_one(my_user)                // ok, User совместим со Display

Self внутри protocol { ... } блока — это «late-bound» тип, определяется при удовлетворении (см. также D66 — Self universal во всех type-контекстах).

Почему

1. Унификация под одним keyword. Все типы (data + behavior) идут через type. Один keyword для объявления, kind-токен различает форму. Согласовано с D52, который вводит alias как kind-токен — protocol встаёт в тот же ряд.
2. Снимается асимметрия. До D53: protocol Foo — отдельный keyword, но Foo использовался как тип (в позиции параметра). Программист спрашивал «если protocol — тип, почему не объявляется через type?». D53 отвечает: теперь объявляется.
3. Анонимные protocol-типы становятся явными. Раньше fn f(x { ... }) без префикса — двусмысленно (record-литерал? record-тип? protocol-тип?). С protocol { ... } — намерение явно.
4. any — пустой именованный protocol. Простое и согласованное решение для top-type, через ту же систему. Прецедент Go (type any = interface{}), Swift (protocol AnyObject { }).
5. Прецедент Go. Go объявляет type X struct { } и type X interface { } через единый type с kind-токеном. D53 повторяет эту схему точно (только interface → protocol).
6. AI-friendly. Один keyword type в начале — LLM сразу видит «это объявление типа», kind показывает форму. Меньше keyword’ов для запоминания.

Что отвергнуто

• Сохранить protocol Foo { ... } как отдельный keyword (текущий D42). Создаёт асимметрию: data объявляется через type, behavior — через protocol, оба используются как типы — два пути к одной концепции «тип». D53 устраняет.
• type any alias protocol { } как форма для any. Для protocol’ов alias-форма семантически тождественна newtype-форме (структурная типизация делает имена незначимыми). Дополнительный синтаксис без выигрыша. Прямая type any protocol { } короче и яснее.
• Any (PascalCase). Согласовано с D30 строже, но any lowercase привычнее (Go, TS) и согласовано с примитивами.
• Анонимный protocol без префикса { ... }. Двусмысленно с record-литералами и блок-выражениями. protocol { ... } всегда явно.
• Литеральные protocol’ы со значениями полей (как interface{} в Go допускает методы и встраивание других interface’ов через composition). Composition protocol’ов (Foo : Bar) — открытый вопрос (см. D42 раздел «Открытые вопросы»), не входит в D53.

Цена

1. Большой breaking change. Все protocol Foo { ... } в spec/, decisions/, examples/ переписать в type Foo protocol { ... }. Это — повторение масштаба D52 миграции.
2. На одно слово длиннее. type Hash protocol { ... } против protocol Hash { ... } — лишний type (5 символов).
3. protocol теперь kind-токен, не keyword. Грамматически разные роли (kind-token ≠ leading keyword), хотя пишется одинаково.
4. Анонимные protocol-типы в позиции параметра — новая форма, старая (без префикса) запрещена. Все fn f(x { method() }) → fn f(x protocol { method() }).
5. Q22 закрывается этим решением — больше не открытый вопрос.

Связь

• D17 — старая система объявлений, revised → D52.
• D52 — D53 расширяет: protocol встаёт в ряд kind-токенов рядом с alias.
• D42 — D53 заменяет protocol keyword на kind-токен. Семантика структурной типизации и generic-параметров сохраняется.
• 04-effects.md → D18 — эффект как использование protocol-типа в позиции эффекта. Меняется только объявление.
• 08-runtime.md → D26 — any добавлен в prelude.
• 03-syntax.md → D30 — naming: any lowercase как исключение, по аналогии с примитивами.

Открытые вопросы

• Type-pattern-match для значений any. Извлечение конкретного типа из any-значения (match x { int(n) => ..., str(s) => ... }) требует runtime-tag и новой формы match. Не входит в D53.
• Composition protocol’ов (Foo : Bar или Foo extends Bar) — не входит, см. Q21 «proliferation эффектов» как родственный вопрос.

Эволюция

D42 ввёл protocol как отдельный keyword. После D52 (kind-токены alias) выявилась асимметрия: protocol используется как тип, но объявляется не через type. D53 снимает асимметрию — protocol становится kind-токеном в системе D52, унифицируя объявление всех типов под единым keyword’ом.

Q22 («унификация type/protocol») — закрыт принятием D53.

Method-prefix в protocol-блоке (Plan 17 Ф.1)

В protocol-объявлении instance-методы можно писать в обеих формах — и с префиксом @, и без. Они эквивалентны:

type Hash protocol {
    hash() -> u64                    // ✅ голое имя
    eq(other Self) -> bool
}

type Hash protocol {
    @hash() -> u64                   // ✅ с @, симметрия с реализацией
    @eq(other Self) -> bool
}

@ факультативен потому что в protocol-блоке метод всегда instance — без receiver-выражения, контекст однозначный. С @ форма читается как «копия декларации из реализации» (точно как fn User @hash() -> u64); без @ — короче. Структурная совместимость работает одинаково.

Когда писать что:

• @method() — для визуальной симметрии с реализацией; для объявлений где соседние static-методы (если они появятся через Q-static-method-protocol) пишутся через .method().
• method() — для краткости в простых protocol’ах.

Mut-методы — mut @method() обязательно с @ (mut-modifier требует receiver-маркера; голое mut method() отвергнуто как двусмысленное с mut-binding’ом):

type Iter[T] protocol {
    mut @next() -> Option[T]         // ✅
    mut next() -> Option[T]          // ✅ (текущая prelude-форма, D26)
}

В bootstrap’е (2026-05-08) обе формы парсятся; std/testing/property.nv и std/collections/* используют голую форму.

См. также Q-protocol-method-prefix (closed этой секцией).

Реализация в bootstrap (2026-05-09)

Plan 15 D53 strict-mode (Plan 15 Ф.5) ввёл различие protocol/effect на уровне AST. Раньше оба keyword’а маршрутизировались в один TypeDeclKind::Effect(Vec<EffectMethod>), что нарушало D72: любой method-bag тип permissively принимался как generic-bound.

Текущее состояние:

• TypeDeclKind::Protocol(Vec<EffectMethod>) — для type X protocol {…}.
• TypeDeclKind::Effect(Vec<EffectMethod>) — для type X effect {…}.
• Парсер маршрутизирует по ключевому слову (отдельные match-arm).
• Codegen эмитит vtable только для Effect-kind. Protocol — compile-time-only; type_ref_to_c для protocol-методов не вызывается. Это попутно зафиксировало pre-existing bug: Self в protocol-методе раньше ломал codegen (искал несуществующий Nova_Self*).
• Type-checker (D72 enforcement) регистрирует только Protocol-kind в protocol_specs. Попытка использовать Effect как bound — compile error c hint’ом «X is an effect, not a protocol — declare as type X protocol {…}».
• Анонимные protocol-литералы в позиции типа (fn close(c protocol { close() -> () }), §628 этой секции) — ✅ реализованы в Plan 97 Ф.2 через новый TypeRef::Protocol(ProtocolSig) variant.
• Protocol-литералы в expression-position (let l = protocol Name { ops }) с runtime vtable + dispatch — ✅ реализованы в Plan 97.1 (codegen vtable struct + emit_protocol_lit + Plan 56 D122 box-pattern). См. также D142.

D55. Literal coercion в позиции с явным типом: sum-конструкторы и record-литералы

Что

В позиции, где компилятор явно знает целевой тип T (let с аннотацией, аргумент функции, return-выражение), литерал автоматически подгоняется под T. Четыре случая:

1. Sum-coercion. Значение типа S оборачивается в единственный unary-конструктор C(S) sum-типа T.
2. Record-coercion. Анонимный record-литерал { field: value, ... } получает тип T без необходимости писать имя типа перед {}.
3. Map-coercion. Анонимный record-литерал { name: value, ... } в позиции, ожидающей str-keyed map (тип помечен атрибутом #from_fields, как HashMap[str, V]), превращается в map: имена полей становятся строковыми ключами. Это не record-coercion (поля литерала ≠ поля struct’а HashMap) — отдельное правило, см. ниже.
4. Numeric literal coercion. Целочисленный литерал в позиции numeric-типа (u8, u16, u32, u64, i8, i16, i32, i64, int) принимается без явного as-cast если значение влезает в диапазон целевого типа. Это распространяется на аргументы функций (включая generic после конкретизации: Vec[u8].push(1)), let с аннотацией (ro a u8 = 42), поля record-литерала. Выход за диапазон — compile error E_LIT_OUT_OF_RANGE: ro a u8 = 300 → 300 > u8.MAX (255), ro b u8 = -1 → -1 < u8.MIN (0).

Без runtime-cost, без subtyping. После coercion тип значения — сам T.

// Sum-coercion
type StrOrInt enum S(str) | I(int)

ro a StrOrInt = "test"          // компилятор: a = S("test")
ro b StrOrInt = 25               // компилятор: b = I(25)

fn process(x StrOrInt) -> str => ...
process("alice")                   // компилятор: process(S("alice"))
process(42)                        // компилятор: process(I(42))

// Record-coercion
type User { id u64, name str }

ro u User = { id: 2, name: "Bob" }    // компилятор: u = User { id: 2, name: "Bob" }

fn create_user() -> User =>
    { id: 3, name: "Carol" }            // компилятор подставляет User

fn save(u User) -> () => ...
save({ id: 4, name: "Dave" })           // компилятор: save(User { ... })

Правило

Позиции с «явно ожидаемым типом»

Coercion (и sum-, и record-вариант) применяется только там, где компилятор точно знает целевой тип:

В позициях без явного типа никакая coercion не применяется — литерал имеет «свой» тип ({ id: 2 } — анонимный record, 42 — int, и т.д.).

Статус реализации (2026-05-15). В bootstrap-компиляторе sum-/record-/map-coercion для безымянного литерала реально работает в позициях, помеченных ✅ (включая аргумент-позицию после Plan 52 Ф.3a — f({...}), f([k:v]), named-args). Для ⛔-позиций безымянный { ... } пока даёт codegen-ошибку — там пиши T { ... }. Полная реализация D55 во всех позициях — отдельная задача (investigation в Plan 51 показал, что «~900 избыточных мест» — переоценка; основная масса — это перенос имени, а не устранение).

⚠️ Пример save_all([{id:1,name:"a"}, ...]) ниже некорректен для bootstrap’а. Элемент-позиция литерала коллекции ([]T) помечена ⛔ — coercion на элементах массива пока не работает. Пример станет валиден после расширения Ф.3a на element-positions (за scope Plan 52). Пока там нужен [User{...}, ...] с явным именем типа на каждом элементе.

Запрет дублирования имени типа (Plan 51)

Там, где компилятор знает целевой тип, имя типа в record-литерале избыточно и запрещено — тип объявляется ровно один раз. Enforce’ится в двух позициях:

-> Self резолвится к типу receiver’а (-> Self => Counter { ... } в методе Counter — тоже избыточно). Правило не срабатывает, когда тип литерала ≠ целевой тип — это sum-coercion (fn f() -> Result[U,E] => U { ... }, fn g() -> Shape => Circle { ... }): имя варианта обязательно. Применяется к fn, @-методам и closure-full с =>-телом.

Sum-coercion

В позиции с явным ожидаемым типом T (sum-тип) значение типа S оборачивается, если:

1. У T ровно один unary-конструктор C(S), принимающий тип S.
2. Значение точного типа T уже не подходит (нет exact match).

Стандартные prelude-типы:

ro m Maybe[int] = 42                        // Just(42)
ro r Result[User, str] = User { ... }       // Ok(User { ... })
ro opt Option[str] = "alice"                // Some("alice")

Коллекции:

type SqlValue enum I(i64) | F(f64) | S(str) | B(bool) | Bytes([]u8) | Null

ro args []SqlValue = [42, "alice", true]    // [I(42), S("alice"), B(true)]

// В sql`...` тэге интерполяции тоже coerce'ятся: i64 → I, str → S, bool → B
ro q = sql`SELECT * FROM users WHERE id = ${42}`   // args = [I(42)]

Генерики:

type Wrapper[T] enum W(T) | Empty

ro w Wrapper[int] = 42                      // W(42)
ro w Wrapper[str] = "test"                   // W("test")

Record-coercion

В позиции с явным ожидаемым record-типом T анонимный record-литерал { field: value, ... } подгоняется под T. Имя типа перед {} писать не нужно — компилятор подставляет.

type User { id u64, name str }

ro u User = { id: 2, name: "Bob" }
// эквивалент:
ro u User = User { id: 2, name: "Bob" }

fn save(u User) -> () => ...
save({ id: 4, name: "Dave" })             // эквивалент save(User { ... })

fn create() -> User =>
    { id: 5, name: "Eve" }                 // эквивалент User { id: 5, name: "Eve" }

fn make_default() -> Account =>
    { id: 1, balance: 0, closed: false }   // в return-позиции с типом Account

Правила:

1. Все обязательные поля должны присутствовать в литерале — как и для именованного record-литерала (D17 construction всегда требует все поля).
2. Имена и типы полей должны точно соответствовать T. Лишнее поле или несовпадение типа — ошибка компиляции.
3. Field punning (D17) работает: let u User = { id, name } если id и name — переменные в скоупе.
4. Без явного целевого типа литерал { id: 2, name: "Bob" } остаётся анонимным record-значением. Тип параметра функции или аннотации let активирует coercion.

Композиция с sum-coercion:

ro r Result[User, str] = { id: 2, name: "Bob" }
// шаг 1 (record-coercion): { id: 2, name: "Bob" } → User { id: 2, name: "Bob" }
// шаг 2 (sum-coercion): User → Ok(User { ... })

Записывается как одно действие компилятора в позиции с явным типом Result[User, str]. Один-единственный record-литерал → User → Ok.

Симметрия с массивами:

То же type-driven поведение работает для массивов и других литералов в позиции аргумента — это та же модель, которой Nova уже пользуется для пустых массивов:

fn first[T](xs []T) -> Option[T] => ...
ro r = first([])                   // [] : []T, T выводится из контекста

fn save(u User) -> () => ...
save({ id: 2, name: "Bob" })        // { ... } : User, тип параметра известен

fn save_all(us []User) -> () => ...
save_all([{ id: 1, name: "a" }, { id: 2, name: "b" }])
// каждый { ... } получает тип User из контекста []User

Аннотация типа параметра — единственный «локальный контекст», который читается, и он рядом с вызовом.

Sum-варианты с record-формой не получают анонимной формы — программист пишет конструктор:

type Shape enum Circle { radius f64 } | Square { side f64 }

ro s Shape = Circle { radius: 5.0 }   // явный конструктор обязателен
ro s Shape = { radius: 5.0 }           // ОШИБКА: по полям невозможно
                                        // выбрать между Circle и Square
                                        // (даже если у них разные поля,
                                        // программист пишет имя варианта)

Это сознательное ограничение: sum-варианты с record-формой требуют имени конструктора всегда. Иначе at parse-time нужно матчить по структуре полей — type-driven parsing, антипаттерн.

Map-coercion

В позиции с явным ожидаемым типом HashMap[str, V] анонимный record-литерал { name: value, ... } превращается в str-keyed map: имена полей литерала становятся строковыми ключами, значения — значениями map.

ro h HashMap[str, bool] = { debug: true, verbose: false }
// эквивалент: HashMap[str, bool] с ключами "debug", "verbose"

fn configure(opts HashMap[str, int]) -> () => ...
configure({ width: 80, height: 25 })          // ключи "width", "height"

Почему отдельное правило, а не record-coercion. HashMap[K, V] — это struct (type HashMap[K, V] { buckets, count, ... }). Обычная record-coercion матчила бы { debug: ... } против полей struct’а HashMap (buckets, count) и падала бы. Map-coercion трактует имена полей литерала как ключи, а не как поля struct’а. Чтобы компилятор знал, какое из двух правил применить, целевой тип несёт #from_fields атрибут (TypeAttr, ставится перед type):

• Это не opt-in ради эргономики (которое D55 отвергает для sum/record) — marker здесь load-bearing для дисамбигуации: «трактовать {...} как поля этого struct’а» vs «как строковые ключи». Без него правило неоднозначно.
• Gating: HashMap[str, V] несёт marker; случайный struct — нет, и не начнёт принимать произвольные record-литералы.
• Bootstrap: marker захардкожен для HashMap. Протокол FromFields[V] как точка расширения (OrderedMap, BTreeMap[str, V]) — позже.
• Протокол #from_fields: тип обязан иметь:
  • static with_capacity(n int) -> Self — предаллоцировать под n записей;
  • mut @insert_new(key str, val V) -> () — вставить новую запись (без возврата Option; дублей нет по construction). Отсутствие любого из методов → CC-FAIL при десугаринге.

Правила:

1. Ключи — только str (имена полей литерала). Нестроковые ключи, не-идентификаторные строки, вычисляемые ключи — это map-литерал [k: v] (03-syntax.md → D108), не {...}.
2. Значения гомогенны — все поля одного типа V (после возможной sum-coercion на каждом значении).
3. Композиция с sum-coercion:

   ro j HashMap[str, JsonValue] = { name: "alice", age: 30.0 }
   // "alice" → Str("alice"), 30.0 → Num(30.0); оба → JsonValue
   

4. Десугаринг — без промежуточных объектов: block-expression с with_capacity + @insert_new, никакой промежуточный record не материализуется (литерал — только синтаксис):

   { mut _m0 = HashMap[str, V].with_capacity(n)
     _m0.insert_new("debug", true)
     _m0.insert_new("verbose", false)
     _m0 }
   

   (@insert_new вместо @insert — мапа только что создана, дублей нет, нет нужды в Option[V]-возврате.)
5. Пустой {} — это НЕ пустая мапа. {} всегда парсится как пустой block-expression с типом unit — даже в позиции, ожидающей HashMap[str, V]. Пустая мапа записывается как [] + ожидаемый тип (03-syntax.md → D108):

   ro h HashMap[str, bool] = []     // ✅ пустая мапа (тип из контекста)
   ro h HashMap[str, bool] = {}     // ⛔ {} — пустой блок, тип unit ≠ HashMap
   

   Ревизия (Plan 52 Ф.0). Прежняя формулировка §5 ошибочно допускала {} в map-позиции → HashMap[str, V].new(). Это требовало type-directed parsing блока — Nova этого не делает (D43). Правило удалено; пустая мапа — только [].

6. Дубликаты ключей невозможны — имена полей record-литерала уникальны by construction.

Граница с map-литералом [k: v]: {...} — когда ключи это статические имена-идентификаторы; [...] — когда ключи это выражения (см. D108).

Когда coercion НЕ применяется

Ambiguity — несколько конструкторов с тем же типом (sum-coercion):

type Ambiguous enum A(int) | B(int)

ro x Ambiguous = 42         // ОШИБКА: ambiguous, A(42) или B(42)?
ro x = A(42)                 // явный конструктор — ok

Несоответствие — ни один конструктор не принимает тип значения:

type Color enum Red | Green | Blue

ro c Color = "red"           // ОШИБКА: ни один конструктор не принимает str
ro c = Red                    // unit-конструктор

Без аннотации — coercion отключён:

type StrOrInt enum S(str) | I(int)

ro a = "test"                // a : str (не StrOrInt, аннотации нет)
ro b StrOrInt = "test"        // b : StrOrInt = S("test") (аннотация есть)

ro r = { id: 2, name: "Bob" }   // r : анонимный record { id int, name str }
ro u User = { id: 2, name: "Bob" }   // u : User (через record-coercion)

Newtype через D52 — coercion следует типу значения, не возможным кастам:

type UserId u64
type Wrapper enum W(UserId) | N(int)

ro w Wrapper = 42            // 42 : int → N(42) (тип значения int)
ro w Wrapper = 42 as UserId  // → W(42 as UserId) — явный as, потом coercion
ro w Wrapper = UserId(42)    // явный конструктор UserId

Несовпадение полей record:

type User { id u64, name str }

ro u User = { id: 2 }                    // ОШИБКА: missing field `name`
ro u User = { id: 2, name: "Bob", age: 30 }   // ОШИБКА: unknown field `age`
ro u User = { id: "two", name: "Bob" }   // ОШИБКА: id expects u64, got str

Coercion не строит цепочку конверсий — только одна обёртка вокруг exact-type значения.

Multi-parameter и tuple-варианты

Multi-parameter конструкторы — coercion не применяется в MVP:

type Event enum Click(int, int) | KeyPress(str)

ro e Event = "enter"         // ok — KeyPress("enter"), unary с str
ro e Event = (5, 10)          // ОШИБКА в MVP: tuple-coercion не вводится
ro e = Click(5, 10)           // явный конструктор

Tuple-coercion (5, 10) → Click(5, 10) — отложено. Усложняет правила (как различать «tuple как значение» vs «tuple-coercion в multi-param»), не критично для use-case’ов.

Unit-конструкторы — coercion бессмыслен

Unit-варианты не принимают значение, coercion не нужен — программист пишет конструктор напрямую:

type State enum Open | Closed
ro s State = Open              // unit, coercion не применяется

Почему

1. Огромный win в эргономике для prelude-типов. Option[T] и Result[T, E] — самые частые sum’ы языка. Без coercion программист пишет Some(42), Ok(user) каждый раз. С coercion — 42, user. Убирает значительную часть boilerplate.
2. Без subtyping. Тип значения после coercion — сам sum или сам record, не подтип. На уровне типов всё чисто: pattern match exhaustive, variance не возникает. Anonymous unions (TS-style string | number) не вводятся — coercion не делает того же эффекта семантически.
3. Без runtime-cost. Sum-обёртка — обычный конструктор, runtime-tag уже есть в representation sum’а (D52). Record-coercion — это просто подстановка имени типа, никакого runtime-преобразования.
4. Закрывает use-case’ы any (sum) и убирает шум именования (record). sql\…${value}`теперь type-safe —valuecoerce'ится вSqlValueбез[]anyи безis-extract. let u User = { id: 2, name: “Bob” }` — без повтора имени типа.
5. AI-friendly. LLM пишет [42, "alice"] для SQL-аргументов естественно, без думания о конструкторах. { id: 2, name: "Bob" } в позиции с явным типом — естественный способ создать record. Имя типа из аннотации — единственный «локальный контекст», который нужно прочитать, и он уже рядом.
6. Прецеденты:
   • Swift ExpressibleByStringLiteral/ExpressibleByIntegerLiteral — opt-in protocol’ы для coercion. Nova делает это автоматически для unary-конструкторов sum’ов (без opt-in).
   • Scala 3 Conversion[A, B] — opt-in given-конверсии.
   • TypeScript — через subtyping для anonymous union, через structural typing для record (const u: User = { id, name } работает). Nova даёт похожую эргономику без subtyping.
   • Rust struct expressions требуют имени (User { id, name }) — прецедент против record-coercion. Nova выбирает TS-эргономику для record в позиции с явным типом, но только в этой позиции.

Что отвергнуто

• Subtyping (int <: StrOrInt) — TS-style anonymous unions. Серьёзное расширение системы типов (variance, type inference, exhaustiveness), runtime-cost (boxing на каждой границе). Coercion даёт то же удобство без subtyping. Записан как Q-anonymous-union для возможного пересмотра.
• Anonymous record-coercion вне позиций с явным типом. let x = { id: 2, name: "Bob" } остаётся анонимным record-типом, не превращается в User. Только явный целевой тип активирует coercion. AI-locality сохраняется.
• Record-coercion для sum-вариантов с record-формой (type Shape | Circle { radius f64 } | Square { side f64 }, let s Shape = { radius: 5.0 }). Программист обязан писать имя варианта (Circle { radius: 5.0 }), даже если поля уникальны для одного варианта. Альтернатива — type-driven parsing по совпадению полей, антипаттерн в Nova.
• Tuple-coercion в MVP. Двусмысленность с tuple-литералами как значениями. Отложено до v1.0+.
• Coercion на цепочках конверсий (int → UserId → Wrapper). Только одна обёртка. Иначе правила усложняются, и легко получить неожиданный результат.
• Coercion без явной аннотации типа (let x = "test" → выводить StrOrInt?). Type inference не должен «угадывать» sum или record. Только явный target type активирует coercion.
• Opt-in coercion через protocol (Swift-style ExpressibleBy*Literal). Программист объявляет sum/record, поведение работает автоматически без дополнительного opt-in. Это менее гибко, но проще.
• Coercion для multi-parameter конструкторов через tuple ((5, 10) → Click(5, 10)). Отложено как tuple-coercion в MVP.

Цена

1. Implicit conversion — первая в Nova. До D55 язык избегал неявного. Это философский сдвиг, обоснованный эргономикой prelude-типов и анонимных record. AI-friendly: LLM не должна угадывать конструктор или имя типа.
2. Type-checker сложнее. В позиции с явным типом нужно проверить exact match, потом coercion (sum или record). Стандартное расширение, но code path не нулевой.
3. IDE-подсказки усложняются. «Ожидается StrOrInt, передан str → coerce в S», «Ожидается User, передан анонимный record → подгонка под User» — IDE должна это показывать.
4. Migration sum’а опасна: добавление нового unary-конструктора с тем же типом параметра ломает существующий код (был exact match через coercion в S(str), стал ambiguous из-за S(str) | S2(str)). Это breaking change для sum’а — программист должен учитывать.
5. Migration record’а тоже: добавление обязательного поля в record ломает все анонимные литералы без него. Это известная проблема record-типов вообще, не специфическая для D55.
6. Закрывает большую часть use-case’ов any — это плюс, но требует пересмотра примеров (args []any → args []SqlValue).
7. Парсер — без type-driven decisions. Coercion работает в позициях, где целевой тип уже известен type-checker’у — парсер по-прежнему чисто синтаксический. {...} парсится как record-литерал/block-выражение по обычным правилам D17/D49, а тип ему присваивает type-checker по аннотации.

Связь

• D52 — sum-типы и unary-конструкторы, на которых coercion работает.
• D53 — any остаётся для подлинно открытых случаев (plugins, reflection), D55 закрывает большую часть use-case’ов через closed sum’ы.
• 03-syntax.md → D44 — numeric literal coercion (100 подгоняется под u8/u32 в позиции типа) — D55 расширяет эту идею на sum’ы и record’ы.
• 03-syntax.md → D54 — as/is остаются явными для конвертации/проверки. D55 не вводит implicit cast между обычными типами, только для sum-обёрток и record-литералов.
• 08-runtime.md → D26 — Option[T], Result[T, E] в prelude получают эргономичный синтаксис через D55.
• #d17-объявление-типов-единый-синтаксис-без- (revised → D52) — record-литерал User { id: 1, name: "alice" } с именем типа — обязательный, когда тип не выводится из контекста. D55 разрешает опускать имя в позиции с явным целевым типом.
• 03-syntax.md → D108 — map-литерал [k: v]; комплементарен map-coercion ({...} — ключи-имена, [...] — ключи-выражения). Реализация обоих — Plan 52.

Открытые вопросы

• Tuple-coercion для multi-parameter конструкторов. Отложено.
• Anonymous unions (type StrOrInt | type str | type int) — TS-style без обёрток. Записан как Q-anonymous-union (требует subtyping, серьёзное расширение системы типов). См. open-questions.md.
• Стандартные closed sum’ы в prelude (SqlValue, JsonValue) — что именно положить, формат и набор операций. См. Q9 (stdlib).
• Cross-type numeric coercion в D55 (42 → f64 для Number(f64)). Сейчас строгий exact match. См. Q-numeric-coercion.

Style-guide: когда coerce, когда писать тип явно (Plan 17 Ф.1)

D55 разрешает обе формы — coerce и явный конструктор. Чтобы кодовая база не превращалась в смесь стилей, ниже рекомендации для nova fmt/линтера и code review (это не правило компилятора, оба варианта остаются валидными).

Coerce (короче, тип в аннотации) — предпочитать когда:

// 1. let с явной аннотацией — тип сразу слева, имя справа лишнее
ro u User = { id: 1, name: "alice" }                ✅
ro m Maybe[int] = 42                                 ✅

// 2. return-position в expression-body, есть -> T
fn make_default() -> Account => { id: 0, balance: 0 } ✅

// 3. call-site с явным типом параметра — coercion даёт чистый литерал
serve({ ...SERVER_DEFAULTS, port: 9000 })             ✅

// 4. коллекции с разнородными элементами в позиции []SqlValue
ro args []SqlValue = [42, "alice", true]             ✅
//                    [I(42), S("alice"), B(true)]    ❌ шумно

Явный конструктор — предпочитать когда:

// 1. let без аннотации — coercion не работает, имя обязательно
ro r = if cond { Some(value) } else { None }         ✅
ro r = if cond { value } else { None }               ❌ — нет аннотации

// 2. match-arms где хотя бы одна ветка — unit-вариант (None / Empty)
//    — для визуальной симметрии писать ВСЕ ветки с конструкторами
match @cache.get(key) {
    Some(v) => Some(v)            ✅ симметрично с None
    None    => fallback()
}
match @cache.get(key) {
    Some(v) => v                  ❌ value слева, None справа —
    None    => fallback()         //    асимметрично, читать сложнее
}

// 3. nested record-литерал внутри блока — { {...} } визуально шумно
fn compute() -> Money =>
    if special { Money { amount: 100, currency: usd } }   ✅
    else       { Money { amount: a + b, currency: c } }
fn compute() -> Money =>
    if special { { amount: 100, currency: usd } }          ❌ шум
    else       { { amount: a + b, currency: c } }

// 4. ambiguous unary-конструкторы (compile-error без явного имени)
type Mixed enum A(int) | B(int)
ro x Mixed = 42                  ❌ ambiguous — обязателен A(42) / B(42)

Сводка:

Аргумент. nova fmt не должен переписывать одну форму в другую — выбор стилистический. Линтер может в будущем выдавать подсказку для самых тяжёлых случаев (например, { {...} } в block-context), но без флага --strict-style — это рекомендация, не ошибка.

См. также Q-style-coercion (закрыт этой секцией).

Эволюция

До D55 sum-варианты требовали явный конструктор на каждом значении (Some(42), Ok(user), S("test")), а record-литералы — имя типа перед {} (User { id: 1, name: "alice" }).

После D55 в позиции с явным целевым типом:

• sum-значение оборачивается автоматически (42 в позиции Maybe[int] → Just(42)),
• анонимный record-литерал получает имя из аннотации ({ id: 1, name: "alice" } в позиции User → User { id: 1, name: "alice" }).

Это эргономический сдвиг уровня D52, без слома типовой модели.

Альтернатива (anonymous unions через subtyping) рассмотрена и отвергнута — слишком серьёзное расширение системы типов для эргономического выигрыша. D55 даёт похожее удобство более узким и контролируемым механизмом.

D42. protocol keyword для структурных интерфейсов

⚠️ REVISED. Заменено D53. protocol — теперь не отдельный keyword, а kind-токен в системе D52: type Foo protocol { ... }. Семантика структурной типизации, generic-параметров и эффектов сохраняется. Текст ниже — для исторической справки.

Что

Структурные интерфейсы объявляются отдельным keyword protocol. type — для данных (record, sum-type, alias), protocol — для поведения (набор методов как контракт). Любой тип со структурно совпадающими сигнатурами автоматически удовлетворяет protocol’у — без явных impl-блоков.

Эффекты — это тоже protocol, использованный в позиции эффекта (между ) и ->). Один и тот же protocol может играть роль эффекта или роль структурного контракта-параметра — различение по контексту использования (04-effects.md → D18). type без полей с одними методами не допускается — нужен protocol.

Правило

type Hash protocol {        // D52/D53: kind-токен `protocol` под `type`
    hash() -> u64
    eq(other Self) -> bool
}

type Iterator[T] protocol {
    next() -> Option[T]
}

type Login {                    // record (данные) — голый type
    username str
    password str
}

Self внутри protocol-блока — late-bound. См. D66 для других контекстов где Self тоже валиден (static/instance методы, effects).

Структурная совместимость — автоматическая. Метод определяется у типа через @-синтаксис (03-syntax.md → D35) и без дополнительных деклараций удовлетворяет protocol’у:

type User { id u64, name str }

type Display protocol {
    show() -> str
}

fn User @show() -> str => "User(${@name})"

fn log_one(x Display) Log -> () =>
    Log.info(x.show())

log_one(my_user)                // ok, User автоматически совместим

Параметр функции может декларировать требования прямо в типе, без именованного protocol’а:

fn log_one(x { show() -> str }) Log -> () =>
    Log.info(x.show())

В protocol fn-префикс не нужен — там по определению все «члены» это методы. В record-типе поле-функция объявляется явно с fn:

type Button {
    text str
    on_click fn() Io -> ()      // поле-функция в record, не protocol
}

Generic-параметры: на protocol-уровне vs на методе

В Nova есть две явных модели generic-параметров для protocol’а. Программист выбирает по семантике.

Модель A — generic на protocol (protocol P[T] { ... }). T фиксирован для всего protocol’а: один handler = один T. Все методы видят один и тот же T. Разные T = разные сущности (Iterator[Int] и Iterator[String] несовместимы).

type Iterator[T] protocol {
    next() -> Option[T]
    peek() -> Option[T]
}

type Container[T] protocol {
    add(item T) -> ()
    get(idx int) -> T
    size() -> int                    // методы без T тоже допустимы
}

type Channel[T] effect {            // effect — нужен with-substitution
    send(value T) -> ()
    recv() -> T
}

type Cache[K, V] effect {
    get(key K) -> Option[V]
    set(key K, value V) -> ()
}

Когда применять: когда T — фундаментальная характеристика protocol’а, все или большинство методов работают с этим T, и разные T = разные handler’ы имеют смысл.

Модель B — generic на методе (method[T](...)). T живёт только в скоупе одного метода. Один и тот же handler protocol’а вызывает метод с разными T для каждого вызова.

type Tracer effect {
    span[T](body fn() -> T) -> T          // T живёт только здесь
    measure[U](body fn() -> U) -> Duration  // U независим от T
    set_attr(key str, value Json) -> ()    // методы без generic тоже
}

type Db effect {
    query(q Sql) Fail[DbError] -> []DbRow
    in_transaction[T](body fn() Db Fail -> T) Fail -> T
    // ↑ один Db handler оборачивает любой T
}

Когда применять: когда метод принимает/возвращает любой тип, а сам protocol не привязан к этому типу — один handler работает с любым T для каждого вызова.

Различие в семантике handler’а:

В одном protocol’е можно комбинировать оба механизма:

type Stream[T] protocol {
    next() -> Option[T]                       // T на protocol-уровне
    fold[Acc](init Acc, f fn(Acc, T) -> Acc) -> Acc   // Acc на методе
}

T фиксирован для stream (Stream[int]), Acc независим — fold может собирать в разные accumulator-типы из одного и того же stream’а.

Почему

1. Намерение должно быть явным. Старая форма type X = { методы } визуально совпадала с record-формой type X { поля }, различаясь только знаком =. LLM и человек различали намерение по единственному символу — хрупко. Отдельный keyword делает намерение явным с первого токена.
2. Прецедент. protocol как keyword для интерфейсов используется в Swift, Objective-C, Clojure, Elixir, Python (typing.Protocol). Семантически Nova ближе всего к Python typing.Protocol — чисто структурный subtyping.
3. Эффекты в сигнатурах методов делают protocol строже Go interface — реализация не может привнести эффект сверх объявленного. Это уникальное свойство Nova.

Что отвергнуто

• type X = { методы } — слишком похоже на record, отличается одним знаком =. См. «Почему» выше.
• contract — занято под pre/post-условия (09-tooling.md → D24).
• promise — массовая ассоциация с async (JS Promise).
• interface — слишком сильный nominal-bias (Java/C#).
• trait — обещает Rust-фичи (default impl, supertraits, blanket impl), которых в Nova нет.
• shape — короче, но менее знакомо как keyword.
• ability — образно, но без знакомства; навязывает -able суффикс именам.
• Implicit shared scope для generic-параметров (T в нескольких методах одного protocol’а автоматически означает один и тот же тип). Снижает локальность: чтобы понять [T] в одном методе, нужно прочитать весь protocol-блок и проверить остальные методы. Невозможно выразить «независимый T в разных методах» без смены convention (использования других букв). Прецедентов нет — Rust/Swift/Scala/Haskell все используют либо явный protocol-уровень, либо явный method-уровень. Альтернатива (protocol P[T]) уже даёт ту же семантику явно.

Связь

• 02-types.md → D15 — D15 ввёл структурные интерфейсы; D42 уточняет грамматику отдельным keyword.
• 02-types.md → D39 — use Type для делегации между record-типами; protocol не embed’ится.
• 03-syntax.md → D35 — методы через @ как способ удовлетворить protocol.
• 01-philosophy.md → D1 — protocols + data как фундамент парадигмы.

Открытые вопросы

• Bounds на дженерики — HashMap[K: Hash, V] требует отдельного решения. Сейчас параметр без bound, компилятор полагается на структурное соответствие при использовании.
• Default-методы в protocol — пока запрещены.
• Inheritance protocol’ов — protocol A : B пока запрещено; эквивалент достигается явным включением методов B в A.

Эволюция

Изначально структурные интерфейсы описывались через type X = { методы } (см. D15). D42 заменил эту форму на отдельный keyword protocol. Детали — в history/evolution.md.

D15. Структурные интерфейсы

Status: revised. Роль перешла к protocol keyword (D42).

Что

Изначальный механизм структурных «интерфейсов» в Nova: отдельной концепции interface или trait нет; контракт — это набор сигнатур, любой тип со совпадающими методами автоматически совместим. Сейчас этот механизм обогащён keyword protocol (D42), который делает объявление контракта синтаксически явным.

Правило

Структурная совместимость — автоматическая. Имя контракту даёт protocol:

type Display protocol {
    show() -> str
}

type User { id u64, name str }

fn User @show() -> str => "User(${@name})"

fn log_one(x Display) Log -> () => Log.info(x.show())

log_one(my_user)                // ok, User автоматически совместим

Анонимный структурный тип прямо в сигнатуре параметра — без отдельного имени:

fn log_one(x { show() -> str }) Log -> () =>
    Log.info(x.show())

Что сохранено:

• Эффекты в полях-функциях — часть сигнатуры, проверяются как обычно. Реализация не может привнести эффект сверх объявленного. Это ключевое отличие Nova от Go: контракт жёстче, потому что эффекты — часть сигнатуры.
• Структурная совместимость автоматическая, как в Go.
• Дженерики без bound’ов — требования описываются типом параметра.

Почему

1. Следует из принципа «не добавлять фичи без оправдания центральной идеей или AI-first». Rust-style traits ни тому, ни другому не служат.
2. Унификация: одна концепция «структурный тип» вместо двух («record»
   • «interface»). Меньше синтаксиса — проще для LLM.
3. Эффекты в сигнатурах методов делают структурный тип строже, чем Go interface — это уникальное свойство Nova, которое нельзя получить простым заимствованием Go.

Что отвергнуто

• trait / interface как отдельный keyword с nominal-семантикой (Java/C#/Rust).
• impl Trait for Type блоки.
• [T: Trait] bounds в дженериках.
• dyn Trait vs impl Trait разделение.
• Ассоциированные типы.
• Дефолтные методы.
• Trait-наследование, specialization, HKT.

Цена

• Нет имени для контракта иначе как через protocol. В IDE нельзя «найти всех, кто реализует X» так же легко, как в Rust/Java — поиск идёт по совпадению методов.
• Нет номинальности. Если очень нужна — через newtype-обёртку (паттерн, не фича).

Связь

• 02-types.md → D42 — protocol как явное имя для контракта.
• 02-types.md → D39 — embed/delegation как механизм композиции, не subtyping.
• 03-syntax.md → D35 — @-методы как способ удовлетворить protocol.

Эволюция

Ранние черновики описывали контракт через type X = { методы } — визуально неотличимо от record. D42 ввёл отдельный keyword protocol, сохранив структурную семантику D15. Подробно — в history/evolution.md.

D39. Embed и delegation: use name Type (alias обязателен)

Что

Композиция типов через use name Type внутри record-декларации. Имя поля всегда явное — программист пишет alias в snake_case по D30. Default-имя по типу (Go-style use Type → поле Type) не вводится — нарушает D30 (поля snake_case, типы PascalCase).

Это delegation, не наследование: обёртка не является подтипом встроенного.

Правило

Базовое использование

type AuditedAccount {
    use account Account              // имя поля = "account" (snake_case)
    audit_log []AuditEntry
}

ro acc AuditedAccount = ...

// Auto-proxy: прямой доступ к полям и методам Account
println(acc.balance)                 // = acc.account.balance
println(acc.owner)                   // = acc.account.owner
acc.is_solvent()                     // = acc.account.is_solvent()

// Доступ к встроенному объекту целиком — через имя поля
ro just_account = acc.account

use Account без имени — ошибка компиляции: имя поля обязательно.

type AuditedAccount {
    use Account                      // ОШИБКА: имя поля обязательно
    audit_log []AuditEntry
}

Auto-generated прокси-методы

При use name Type компилятор генерирует прокси для каждого метода Type:

type Account { balance money }
fn Account @balance_pct(of money) -> f64 => @balance / of * 100.0

type AuditedAccount {
    use account Account
    audit_log []AuditEntry
}

// Компилятор генерирует:
// fn AuditedAccount @balance_pct(of money) -> f64 =>
//     @account.balance_pct(of)

ro aa AuditedAccount = ...
aa.balance_pct(1000.0)               // через auto-proxy

Zero-cost — компилятор инлайнит вызов, никакой vtable.

Грамматика согласована с record-полями

use name Type использует тот же порядок «имя тип», что и обычные поля, параметры функций, let-bindings, for-loop:

type Wrapper {
    item       str                   // обычное поле: имя тип
    use iter   HashMapIter[K, V]     // embed: use + имя тип
    extra      int
}

fn deposit(mut acc Account) -> () => ...   // параметр: имя тип
ro user User = ...                           // ro: имя тип
for id u64 in ids { ... }                     // for: имя тип

Везде имя слева, тип справа — одно правило для всего языка.

use — keyword, не имя поля

use — зарезервированное слово (D29 для импортов

• embed-конструкция здесь). Имя поля use запрещено.

В декларации {use name Type} use — keyword embed-формы; имя поля — alias после use:

type Set[T] {
    use map HashMap[T, ()]           // имя поля — "map"
}

// record-литерал — имя поля
ro s Set[int] = { map: HashMap[int, ()].new() }      // ✓
ro s Set[int] = { use: HashMap[int, ()].new() }       // ✗ use — keyword

// доступ — имя поля
fn Set[T] @len() => @map.len()                          // ✓
fn Set[T] @len() => @use.len()                          // ✗ use — keyword

Override метода

Если тип-обёртка определяет метод с тем же именем — он затмевает делегированный:

type AuditedAccount {
    use account Account
    audit_log []AuditEntry
}

fn AuditedAccount mut @deposit(amount money) {
    @account.deposit(amount)         // явный вызов «родителя» через имя поля
    @audit_log.push(AuditEntry.deposit(amount))
}

mut acc AuditedAccount = ...
acc.deposit(100)                     // вызовет AuditedAccount.deposit

Без @account. в теле — бесконечная рекурсия. Программист обязан явно обращаться к встроенному через имя поля.

Конфликт имён — разные alias-имена

Если два use вводят одинаковые имена методов — программист даёт разные alias-имена и явно решает, через какой:

type Logger effect { log(msg str) -> () }
type Auditor { log(msg str) -> () }

type Combined {
    use console Logger
    use audit Auditor
}

ro c = Combined { ... }
c.log("...")                         // ОШИБКА: ambiguous (оба имеют log)

Решение — явный вызов через имя поля:

fn Combined @log_all(msg str) {
    @console.log(msg)
    @audit.log(msg)
}

ro c = Combined { ... }
c.console.log("...")
c.audit.log("...")

Anonymous embed: use _ Type (без alias-имени)

Альтернатива явному alias — anonymous embed через _:

type Set[T] {
    use _ HashMap[T, ()]
}

ro s = Set[int].new()
s.insert(item, ())          // ✓ через auto-proxy на HashMap.insert
s.contains(item)            // ✓ через auto-proxy
s.len()                     // ✓ через auto-proxy (D117 method-only)

_ — это wildcard: программист сознательно отказывается от имени поля, потому что не нуждается в прямом доступе к встроенному.

Когда использовать

use _ подходит для simple wrappers где:

• Нет необходимости в прямом доступе к встроенному (@base.method()).
• Wrapper-методы не вызывают delegated в своём теле.

Set[T] — типичный case: вся семантика приходит из HashMap через auto-proxy + override на одно поведение (insert возвращает bool вместо Option).

Override через own-methods — работает

Программист может определить wrapper-метод того же имени что у embedded:

type Set[T] {
    use _ HashMap[T, ()]
}

// Override @insert — заменяем семантику
fn Set[T] mut @insert(item T) -> bool {
    // Здесь нельзя обратиться к HashMap.insert напрямую — нет имени
    // поля для @<base>.insert(...). Override полностью заменяет
    // логику.
    Log.info("inserting...")
    // ... custom impl, не делегируя к HashMap
}

Resolution через call-site overload resolution (D84) с override-precedence: own-method (определённый напрямую на receiver) wins over delegated (через use).

ro s Set[int] = ...
s.insert(42)
// → resolve_overload("insert", "Set[int]", [int])
// → 2 candidates: Set.@insert (own), HashMap.@insert (delegated)
// → override-precedence: own wins → Set.@insert
// → no ambiguity error

Когда не использовать

Если wrapper-метод нуждается в @base.method() для делегирования — нужен named alias:

// ✓ named alias — есть `@account` для явного call
type AuditedAccount {
    use account Account
    audit_log []AuditEntry
}

fn AuditedAccount mut @deposit(amount money) {
    @account.deposit(amount)        // explicit base call
    @audit_log.push(AuditEntry.deposit(amount))
}

// ✗ anonymous embed не подходит — нет имени для base call
type AuditedAccount {
    use _ Account
    audit_log []AuditEntry
}

fn AuditedAccount mut @deposit(amount money) {
    ???                             // как вызвать Account.deposit?
                                    // НИКАК — anonymous embed не даёт имени
}

Compile error в этом случае возникает естественно на call-site: программист пишет @deposit(amount) (без имени поля), это рекурсивный вызов Self — бесконечная рекурсия, которая, скорее всего, не то что хотел программист.

Lint-warning (не error) предложит: «possible infinite recursion in anonymous embed override; use named alias for base-call».

Что запрещено

Два anonymous embed одного типа — недопустимо:

// ✗ COMPILE ERROR
type Wallet {
    use _ Account
    use _ Account               // ambiguous — два anonymous Account
}

При вызове w.balance resolution даёт два candidates с одинаковым priority — ambiguity unresolvable, потому что нет имени поля для disambig’а. Compile error при declaration.

Решение — named alias:

type Wallet {
    use primary Account
    use backup Account
}

Резолвинг — общий механизм overload

Anonymous embed не вводит специальных правил в компилятор. Resolution использует тот же resolve_overload (D84) с двумя расширениями:

1. Анонимные embed-методы регистрируются в overload registry с kind = MethodKind::Delegated(via_use_anonymous) — флагом «delegated».
2. Override-precedence: own-methods (без флага) wins over delegated, при прочих равных (тот же receiver, та же arity, те же arg-types).

Это даёт желаемое поведение «own override затмевает delegated» без отдельной declaration-time проверки collision’а.

Сводка use _ Type vs use name Type

use для встроенных типов ([]T, tuples)

use поддерживает не только именованные record-типы, но и встроенные конструкции — массивы ([]T), tuples ((A, B)), и т.п. Имя поля обязательно (как и для именованных типов):

// VecBuf через embed []T — все методы массива доступны
type VecBuf[T] {
    use data []T
    extra str
}

ro v = VecBuf[int] { data: [1, 2, 3], extra: "info" }
ro n = v.len            // прокси-метод к data.len ([]T API)
v.push(42)               // прокси-метод к data.push
ro x = v.get(0)         // прокси к data.get

Этим механизмом строятся «именованные обёртки над массивами» с дополнительными полями/методами без переписывания базового API.

API расширяется обычными методами на типе (D35):

fn VecBuf[T] @first_or_default(def T) -> T =>
    @data.get(0).unwrap_or(def)

API самих встроенных типов ([]T.len, []T.push, etc.) — открытый вопрос Q-array-api в open-questions.md, формализуется в Q9 stdlib.

Что это НЕ

Не наследование. AuditedAccount не является Account:

fn process(a Account) -> () => ...

ro aa AuditedAccount = ...
process(aa)                         // ОШИБКА
process(aa.account)                 // ок: извлекли Account-часть через имя поля

Если нужен полиморфизм — структурный protocol:

type HasBalance protocol {
    balance() -> money
}

fn process(a HasBalance) -> () => ...
process(aa)                         // ок: AuditedAccount имеет balance()
                                    //  через delegation auto-proxy

Не множественное наследование. Можно use несколько типов, но конфликты решаются alias’ом или явным обращением. Diamond-problem не возникает — нет иерархии.

Почему

1. Замена наследования (D1) — embed решает 80% задач композиции без сложности subtyping.
2. Согласованность с D30 naming. Поля Nova — snake_case (D30). Default-имя по типу (Go-style) дало бы PascalCase-поле — нарушение D30. Явный alias обязывает программиста выбрать snake_case, всё единообразно.
3. Согласованность с language-wide порядком. use name Type — тот же порядок «имя тип», что параметры, поля, let-bindings, for-loop. Одно правило для всего языка.
4. AI-friendly. Никакой magic-conversion (HashMap → hashmap/ hash_map?), программист явно выбирает имя поля. LLM не догадывается.

Что отвергнуто

• Default-имя поля по типу (use Account → поле Account, Go-style). Создаёт исключение в D30 (поля PascalCase в одном record-блоке с snake_case полями). Auto-conversion PascalCase → snake_case (HashMap → hash_map?) — magic, не очевидное правило.
• use Type as name (Rust import-style). as зафиксировано для cast в выражениях (D54) и импортов (07-modules.md → D29). В embed — «объявление поля», порядок «имя тип» согласован с остальным языком.
• Subtyping — противоречит D1; полиморфизм через protocol.
• Множественное наследование — известный антипаттерн (diamond, fragile base).

Связь

• 01-philosophy.md → D1 — use как замена наследования.
• 02-types.md → D17 — use внутри record-блока.
• 02-types.md → D15, D42 — полиморфизм для embed-типов идёт через protocol, не через subtyping.
• 03-syntax.md → D30 — naming convention (поля snake_case, типы PascalCase). Обязательность alias следует из D30.
• 03-syntax.md → D35 — @field.method() для явного вызова из метода обёртки.
• 03-syntax.md → D38 — generic-применение в embed: use iter HashMapIter[K, V].

Эволюция

Первая редакция D39 разрешала default-имя = имя типа: use Account → поле Account (PascalCase, Go-style). Это создавало нарушение D30 (поля должны быть snake_case) — в одном record- блоке audit_log (snake) и Account (Pascal) выглядели несогласованно.

Что стало: alias обязателен. use Account без имени — ошибка компиляции, программист пишет use account Account. Default-имя отменено, никакой magic-conversion HashMap → hash_map.

Также поменялся синтаксис конфликтов: раньше предлагался «явный вызов через имя типа» (c.Logger.log(...)), теперь только через alias- имя поля (c.console.log(...)). Это согласовано с тем, что все поля имеют alias-имя, и в коде используется оно.

Q-embed-syntax в open-questions всё ещё открыт — это отдельный вопрос про keyword (use vs embed vs голый тип), а не про обязательность имени.

Anonymous embed (2026-05-08): добавлена форма use _ Type для simple wrappers где явное имя поля бессмысленно (use _ HashMap[T, ()] в Set[T]). Программист не выбирает alias из bikeshedding map/inner/ s/value — _ явно говорит «безымянный embed, прямой доступ не нужен».

Resolution для anonymous через lazy mechanism — общий call-site overload-resolution (D84) с override-precedence (own-method wins over delegated). Никаких declaration-time проверок collision’ов. Это упрощает компилятор — один путь для named и anonymous.

Trade-off anonymous vs named: anonymous теряет @<name>.method() (прямой base-call) и pattern-destructure через имя поля. Эти возможности трактуются как «escape hatches» — для них программист пишет use name Type явно.

Прецеденты:

• Go embedded interface{} — anonymous, прямой доступ через имя типа (s.Account). Nova не следует — D30 запрещает PascalCase поля.
• D alias this — anonymous embed с implicit conversion. Nova не следует — нет subtyping (D1).
• Rust composition — нет anonymous embed; программист пишет field + manual delegation. Nova use _ экономит boilerplate.

Bootstrap status (2026-05-08)

Реализовано в bootstrap-codegen (Plan 11 Ф.9):

• ✅ Parser: use name Type (named embed) и use _ Type (anonymous). Anonymous имя поля — синтетическое __embed_<TypeName>.
• ✅ AST: RecordField.is_embed: bool, RecordField.embed_anonymous: bool.
• ✅ Codegen auto-proxy generation: embed_fields registry per record-type; для каждого Own-метода embedded-типа эмитится Delegated MethodSig + C-функция, которая делегирует через nova_self->field.
• ✅ Override-precedence (Own > Delegated) в emit_call и infer paths (Plan 11 Ф.9.3). Strict-match candidates сначала, затем фильтр Own.
• ✅ Multi-anonymous detection: declaration-time error если ≥2 anonymous embeds одного типа в одном record’е (Plan 11 Ф.9.4).
• ✅ Lint warning possible infinite recursion: при detect own-method override на anonymous embed — stderr-warning о невозможности base-call’а (Plan 11 Ф.9.5).

Bootstrap-ограничения:

• C-name mangling по param-types: для overloaded delegated proxy имена с suffix’ом __<types>, как для own overload.
• Generic embed (use map HashMap[K, V] в generic wrapper) — работает для конкретных type-параметров; full generic monomorphization — открытый вопрос.

D32. Семантика передачи параметров

Status: revised для полей. D36 переписал семантику mut на поле типа. Семантика mut на параметре (этот D32) — без изменений.

⚠️ AMENDED by Plan 118 (D216) — &value operator restored для создания typed pointer (*T / *mut T). Это НЕ Rust borrow (нет lifetime checker, нет XOR aliasing); safety обеспечивается через escape analysis + auto-promote (Go-style) + unsafe gating. D32 spirit «no borrow» preserved — *T это explicit unsafe-gated raw pointer с safety net через GC, не lifetime-checked reference. See Plan 118 §«&value operator + escape analysis с auto-promote» и D216 §4.

⚠️ D32 align (Plan 138.5; amend Plan 147 D246) — мутируемость в указательном типе — это L3 pointee (target), из ТИПА позиционно-независимо: *mut T = writable target, *T = ro-pointee (*T ≡ *ro T УНИВЕРСАЛЬНО; pointee-mut НЕ наследуется от binding — flip-scan-draft отклонён). Перепривязываемость самого указателя — это L1 binding (ro/mut), как у любого параметра/переменной по D32/D36, НЕ часть типа и НЕ влияет на pointee. Prefix-модификатор перед * (mut * T) запрещён (D216 §1 E_POINTER_PREFIX_MODIFIER). Семантика передачи параметров (этот D32) не меняется: mut p *T = mutable binding указателя (p reassignable), доступ к target — по pointee-модификатору типа.

Amended Plan 114 D184 (2026-05-31): default immutable binding теперь выражается через ro X = … (immutable) и mut X = … (mutable); let retracted. Семантика default-immutable не меняется — только keyword. См. D184.

Что

Параметры функций передаются by reference в managed heap (как Java/C# для объектов, Go для maps/slices). Без mut — immutable view, с mut — мутации видны вызывающему. Примитивы (int, bool, f64, …) — by value в регистре. Borrow &T отсутствует как концепция.

Правило

Базовое поведение.

type Account { balance money }

// без mut — функция только читает
fn show(acc Account) Io -> () =>
    println("balance: ${acc.balance}")

// с mut — функция меняет, изменения видны вызывающему
fn deposit(mut acc Account, amount money) {
    acc.balance += amount
}

mut my_acc = Account { balance: 100 }
deposit(my_acc, 50)
// my_acc.balance == 150 — мутация видна

Примитивы — by value. Числа, bool, char, u8, () — всегда копия в регистре. С mut x int это локальная переменная функции, изменения не видны вызывающему:

fn weird(mut x int) {
    x = 999                         // меняет локально
}

ro n = 5
weird(n)
// n == 5 — примитив всегда by value

Явная таксономия value vs reference типов (D215 amend, Plan 120; Receiver mut-ABI column added Plan 128 Ф.5, 2026-06-05):

str reclassified (Plan 139, 2026-06-11): ранее str стоял в одной строке с []T как «managed heap / by reference». Теперь str — value type, несущий heap-backed буфер: само значение — 16-байт stack-value type str value priv { ptr *u8, len int } с copy-семантикой (как примитив/tuple/value-record), а UTF-8 байты живут в heap (RawMem, GC-tracked) либо rodata (литералы). Поэтому передача str — by-value копия 16-байт handle’а (НЕ pointer-to-heap-object), а buffer разделяется immutably через *u8 (ro-pointee, ≡ *ro u8; D246). См. D26 MAJOR AMEND

• D228 «str — канонический reference-field value-record».

Bracket choice явно кодирует size/lifetime semantics: () = stack, {} = heap. Tuple value types (D123): zero GC pressure, predictable lifetime — ideal для hot-path math types, FFI returns, iterator state.

Receiver mut-ABI rationale (Plan 128): value categories (tuples, value-records) — by-value normally, но mut @ receiver требует pointer чтобы мутации были видны caller’у. Reference categories (records, sum-types, arrays, strings) уже passed by pointer — no extra ABI flip. Primitives никогда mut-method (Nova-first idiom: int.add returns new value, не mutates self) — Plan 128 Ф.3 E_PRIMITIVE_MUT_METHOD diagnostic enforces. Threading: MethodCallInfo::recv.mutable flag консолидирует решение, propagated через emit_c.rs::prepare_method_recv (Plan 128 Ф.1).

Объекты (record / sum-type / массивы) — managed reference. Указатель в managed heap, отслеживаемый GC. В синтаксисе программист пишет просто o Order — никакого & или *:

type Order { items []Item, total money }

fn add_item(mut order Order, item Item) {
    order.items.push(item)
    order.total += item.price
}

mut my_order = Order { items: [], total: 0 }
add_item(my_order, item1)
// my_order содержит item1 и обновлённый total

&T (borrow в Rust-стиле) не существует в Nova. Escape analysis закрывает большинство perf-кейсов автоматически; для real-time — region { ... } (05-memory.md → D6).

Иммутабельный binding. Без mut параметр нельзя мутировать ни одно поле (кроме помеченных mut per-field — см. D36):

type Account { balance money }

fn read_only(acc Account) {
    acc.balance += 50               // ОШИБКА: acc immutable
    println(acc.balance)            // ок, чтение
}

Семантика mut на параметре и mut на поле взаимодействуют через правила D36 — для записи нужно соответствие на обоих уровнях.

Производительность. Когда нужна максимальная производительность без GC overhead — escape analysis (автоматически) или region { ... } (05-memory.md → D6):

fn process_audio(samples []f32) Realtime -> []f32 =>
    region {
        ro buf = []f32.with_capacity(1024)
        // обработка, без GC pauses
        buf.to_owned()
    }

Никаких &T borrow, никаких lifetime-аннотаций в обычном коде.

Сводка

Почему

1. Согласовано с managed heap (05-memory.md → D6) — объекты уже в куче, передача указателя дешёвая, копировать бессмысленно.
2. AI-first видимость в типах (01-philosophy.md → D10) — сигнатура fn deposit(mut acc Account, …) против fn show(acc Account) сразу показывает контракт. Java/C#: всё mutable references по умолчанию, программист помнит наизусть.
3. mut — единый префикс для разных случаев (let, поле, параметр). Везде «mut = разрешена мутация» — одно понятие, не разные. Согласовано с D36 и 03-syntax.md → D33.

Что отвергнуто

• By-value для всех типов (Go-стиль). Копирование больших structs дорого, несовместимо с managed heap, программист удивляется «изменил поле — не сохранилось».
• By-reference с обязательным &mut (Rust-стиль). Слишком много синтаксиса для прикладного кода; в Nova mut уже работает для let и полей.
• Move-семантика (Rust для не-Copy). Сложна для прикладного программиста, не нужна с GC.
• Borrow &T. Скопирован в раннем дизайне рефлекторно. Borrow существует в Rust, потому что нет GC; в Nova с GC передача = указатель. Escape analysis + region закрывают остальное. Lifetime checker — research-уровень, цена реализации высокая. Go показывает: без borrow инфраструктура интернета работает.

Связь

• 02-types.md → D36 — пересмотр семантики mut для полей типа. Параметры — без изменений.
• 05-memory.md → D6 — managed heap делает by-reference дешёвым; region для real-time.
• 04-effects.md → D62 — Mut[T] как generic эффект удалён; мутация через mut поля/параметры (локально) или специализированные state-эффекты (Counter/Cache/IdGen).
• 01-philosophy.md → D10 — AI-first видимость мутации в типе.
• 03-syntax.md → D35 — fn Type mut @method использует тот же mut для self-binding’а.

Эволюция

В D32 поле типа mut field мутировалось только у mut-binding’а. Для аккумуляторов (все поля mutable) приходилось писать mut 18 раз — шум без пользы. D36 переписал это: дефолт mutable у mut-binding’а, readonly для never-mut, mut per-field — только для cache/lazy. Семантика параметров не менялась.

D36. Поля типа: дефолт mutable у mut binding’а, ro для never-mut

Amended Plan 114 D184 (2026-05-31): readonly → ro keyword rename в полях. Sample обновлён. Error code E_READONLY_FIELD сохранён как stable API. Семантика per-field freeze не меняется.

Что

Поле без префикса мутируется, если binding mutable. readonly запрещает мутацию даже у mutable binding’а (для id, foreign keys, invariants). mut per-field разрешает мутацию даже у immutable binding’а (для cache, lazy init, atomic counters — аналог C++ mutable). Group-syntax: несколько полей одного типа через запятую.

Правило

Базовое использование.

// Аккумулятор — все поля мутируемые, никаких префиксов не нужно
type RunAcc {
    att_wins int, def_wins int, draws int
    total_rounds int
    total_moon_chance f64
    atk_lost_m int, atk_lost_s int, atk_lost_h int
}

mut acc = RunAcc { att_wins: 0, def_wins: 0, ... }
acc.att_wins += 1                   // ок — binding mut, поле без ro

// Структура с invariant'ами — readonly для read-only полей
type Account {
    ro id u64                 // никогда не меняется
    ro owner str              // тоже
    balance money                    // мутируется у mut binding'а
    closed bool
}

ro acc = Account.new("alice")
acc.balance = 100                   // ОШИБКА: binding не mut

mut acc2 = Account.new("alice")
acc2.balance = 100                  // ок
acc2.id = 999                       // ОШИБКА: id объявлено ro

// Cache/lazy — mut для полей, мутируемых через immutable binding
type LazyConfig {
    path str
    mut cached_value Option[str]    // обновляется при первом read
}

fn LazyConfig @get() -> str {
    if Some(v) = @cached_value { return v }
    ro v = read_file(@path)
    @cached_value = Some(v)         // мутация через @-метод даже у ro-binding
    v
}

Group-syntax. Несколько полей одного типа — через запятую:

type Point { x, y, z f64 }                          // три f64
type Color { r, g, b u8 }                           // три u8
type RunAcc {
    att_wins, def_wins, draws int
    atk_lost_m, atk_lost_s, atk_lost_h int
    atk_lost_pts, def_lost_pts f64
}

С префиксами:

type Account {
    ro id, owner_id u64       // два immutable
    balance money                    // дефолт (mutable у mut-binding)
    mut last_access_time time        // mutable всегда
}

Сводная таблица

Почему

1. Меньше шума для типичного случая. Аккумулятор с 18 mutable полями писать без префиксов — все поля «обычные», никаких акцентов. Раньше 18 раз mut — визуальный мусор.
2. Сигнатура показывает только важное. Префикс ставится только на исключения (readonly для invariants, mut для cache). LLM, читая тип, видит: readonly id — «не трогай», обычное поле — «можно мутировать с mut-binding’ом».
3. Прецедент Rust/Go/C++ — поля без префикса мутируются у mut-binding’а; readonly для never-mut близко к C++ const member.

Что отвергнуто

• Старая семантика D32 (поле mut мутируется только у mut-binding). Заставляет писать mut перед каждым полем аккумулятора; если все поля mut — выделение теряет смысл.
• Rust-полное (поле всегда mutable у mut-binding, нет never-mut). Невозможно зафиксировать read-only invariant без приватного поля + getter.
• type X mut { … } (mut на тип). Один маркер вместо 18 — короче, но при 90% mut + 10% read-only нужен опт-аут per field. Усложнение. Конфликт с современным паттерном «struct + immutable defaults + явная мутация» из Swift/Rust.
• final (Java-стиль) для never-mut полей. Короче, прецедент Java/Dart/Kotlin, но семантически перегружен (final method, final class, final var). readonly прямо говорит «только для чтения».
• let для never-mut полей. Короче (3 символа), прецедент Swift, но let уже значит «binding имени со значением» (03-syntax.md → D33). На поле без = необычно, не самообъясняемо. readonly прямо говорит цель.
• const (C++-стиль). Конфликт с 03-syntax.md → D33 — там const = compile-time константа. Здесь — runtime-immutable. Перегрузка термина, AI-first против — невозможно.

Связь

• 02-types.md → D32 — пересмотр семантики mut для полей. Передача параметров (fn f(mut o Order)) остаётся: mut на параметре = mutable binding, внутри — мутации полей по правилам D36.
• 02-types.md → D17 — group-syntax для полей одного типа внутри record.
• 03-syntax.md → D33 — let это immutable binding; на поле — аналогия в роли readonly.
• 03-syntax.md → D35 — fn Type mut @method даёт mutable-binding self, поля затем по правилам D36.

Эволюция

До D36 поле помечалось mut field T, мутируемое только у mut-binding’а (D32). Для аккумуляторов это требовало 18 раз повторить mut — шум без пользы. D36 инвертировал дефолт: «обычное поле — мутируется у mut-binding’а», readonly — для исключений. Семантика параметров (D32) не менялась. Подробно — в history/evolution.md.

Enforcement (Plan 108.2, 2026-05-30)

Плановое поведение D36 («let без mut — immutable») de-facto существовало с самого начала, но компилятор не enforce’ил его строго: на binding’е без mut можно было вызывать mut-методы (.push, .append, .insert и т.п.) и присваивать поля (b.field = ...). Plan 108.2 закрывает этот gap:

ro b = Box.new(1)
b.value = 99                  // ✗ E_LOCAL_NOT_MUT
b.push(2)                     // ✗ E_LOCAL_NOT_MUT

mut b2 = Box.new(1)
b2.value = 99                 // ✓
b2.push(2)                    // ✓

Правила (Plan 108.2):

consume X = ... неявно подразумевает mut (как consume param в D176 amend Plan 108.1) — ownership transfer → владелец может мутировать.

Symmetry с D176 (Plan 108.1):

Loop-var и pattern-binding (Plan 108.3, 2026-05-30)

Loop-var mutability: в for-цикле переменная итерации по умолчанию read-only. Opt-in mut через for mut x in iter:

for x in arrs { x.push(1) }           // ✗ E_LOCAL_NOT_MUT — x immutable
for mut x in arrs { x.push(1) }       // ✓ — x mutable

Pattern-binding per-name mut: при destructure (tuple, record) mut ставится на каждое имя отдельно, parallel Rust pattern semantics:

ro (a, b) = pair                     // оба immutable
ro (mut a, b) = pair                 // a mutable, b immutable
ro (a, mut b) = pair                 // a immutable, b mutable
ro (mut a, mut b) = pair             // оба mutable

Запрет group-mut: let mut (a, b) = ... отвергается parser-level (E_PATTERN_GROUP_MUT) — keyword mut относится к одному имени, не к pattern целиком (consistent с Rust):

mut (a, b) = pair                 // ✗ E_PATTERN_GROUP_MUT

Использование mut внутри pattern — единственно правильная форма.

Указатели: перепривязываемость = binding (D216 cross-ref, Plan 138.5)

Перепривязываемость указательной переменной (можно ли p = other_ptr) регулируется её binding’ом (ro = фиксирован, mut = reassignable) — ровно как у любой другой переменной по правилам D36 выше. Это НЕ часть типа указателя: указательный тип несёт только мутируемость pointee (target) постфиксом (*mut T / *ro T). Никакого type-level «outer pointer-mut» нет.

ro p *mut int = &x         // p фиксирован (binding ro); target writable (pointee mut)
mut q *ro int = &y         // q reassignable (binding mut); target read-only
q = &z                     // ✓ q — mut binding
p = &w                     // ✗ existing E_REBIND — p ro binding

Две роли чисто разделены: ведущий ro/mut перед именем = binding; *mut/*ro после * = pointee. Prefix-модификатор перед * (mut * T) запрещён (D216 §1 E_POINTER_PREFIX_MODIFIER).

Связь

• 02-types.md → D175 — readonly field полный freeze.
• 02-types.md → D176 — readonly T modifier + Plan 108.1 param default flip.
• 02-types.md → D216 §1/§V2.6 — указатель: pointee-mut в типе (postfix), reassignability = binding (Plan 138.5).
• 03-syntax.md → D33 — let это immutable binding.

D175. ro field — полный freeze (амендмент D36)

📌 Полная модель мутабельности — D246 (3 оси: L1 binding / L2 content-view / L3 pointee). Этот D-блок описывает только L2: freeze поля через ro field. Для общей картины, дефолтов и error-кодов читай D246.

⚠️ См. D216 V3 §V3.1 (Plan 118.5 V3, 2026-06-04/05) для storage-class-aware rules о ro + mut adjacency: type-form ro mut T запрещён на value-T (E_MUTABILITY_CONFLICT_VALUE_TYPE), binding-form ro x mut T allowed regardless of T storage class (Ф.6 relaxation).

Status: active (Plan 108, 2026-05-28); amended Plan 114 D184 (2026-05-31): readonly → ro keyword rename. Error code E_READONLY_FIELD сохранён как stable API. Семантика freeze + транзитивность не меняется.

Что

Уточнение D36: ro field T запрещает и переприсвоение поля, и мутацию содержимого — транзитивно.

Транзитивность: если поле объявлено ro, доступ через него также запрещает мутацию вложенных полей и вызов mut-методов:

type Tags { mut items []str }
type Account {
    ro id u64
    ro tags Tags              // нельзя acc.tags.items.push("x")
}
mut acc = ...
acc.id = 999                  // E_READONLY_FIELD
acc.tags = Tags{}             // E_READONLY_FIELD
acc.tags.items.push("x")      // E_READONLY_FIELD (транзитивно)

Связь

• D36 — расширяется
• D176 — ro как тип-позиция
• D184 — keyword refresh (readonly → ro rename)

D176. ro T — тип-модификатор

📌 Полная модель мутабельности — D246 (3 оси: L1 binding / L2 content-view / L3 pointee). Этот D-блок описывает только L2: ro T как type-modifier + параметры ro по умолчанию. Для общей картины, дефолтов и error-кодов читай D246.

⚠️ См. D216 V3 §V3.1 (Plan 118.5 V3, 2026-06-04/05) для storage-class-aware rules о ro + mut adjacency: type-form ro mut T запрещён на value-T (E_MUTABILITY_CONFLICT_VALUE_TYPE), binding-form ro x mut T allowed regardless of T storage class (Ф.6 relaxation).

Status: active (Plan 108, 2026-05-28); amended (Plan 108.1, 2026-05-30); amended Plan 114 D184 (2026-05-31): readonly → ro keyword rename; return-type defaults + @-inheritance section added. Error codes E_READONLY_CONTENT / E_READONLY_COERCE / E_PARAM_NOT_MUT сохранены как stable API.

Что

ro как prefix-модификатор типа в любой позиции:

fn str @as_bytes() -> ro []u8                 // возвращаемый тип
fn process(data ro []u8) { ... }              // параметр
type Wrapper { field ro []u8 }                // поле
ro view ro []u8 = s.as_bytes()                // binding с ro-content

Двойное ro в последней строке — не tautology: первое ro — binding mutability (нельзя view = …), второе — type-modifier (нельзя view[0] = …). См. D184 для полного дизайна.

Семантика

• Запрещает вызов mut-методов на значении типа ro T
• Запрещает запись через индекс: view[i] = x → E_READONLY_CONTENT
• T → ro T coercion разрешён автоматически (сужение прав)
• ro T → T запрещён: E_READONLY_COERCE

ro arr []u8 = [1, 2, 3]
ro view ro []u8 = arr                 // ✅ []u8 → ro []u8
mut back []u8 = view                  // ❌ E_READONLY_COERCE
view[0] = 99                          // ❌ E_READONLY_CONTENT
take_ro(arr)                          // ✅ auto-coerce при вызове

Return-type defaults + @-inheritance (Plan 114 D184)

Асимметрия с параметрами — намеренная. Plan 108.1 сделал параметры default ro (callee не может мутировать без opt-in). Для возвращаемых значений правило противоположное: default = mutable (caller получает значение, делает с ним что хочет).

fn make_buf(n int) -> []u8                  // -> mutable []u8 by default
fn read_view(s str) -> ro []u8              // explicit ro в возврате

Обоснование. Param ro default — defensive (callee не имеет права). Return mut default — permissive (caller владеет результатом). Это совпадает с Rust/Swift/Kotlin: fn foo() -> Vec<T> отдаёт owned mutable; чтобы вернуть read-only view — explicit -> ro T.

Особый случай: pointer-returns (D216 amend, Plan 138.5; D246). Pointee-mut возвращаемого указателя — это L3, из ТИПА (*T=ro / *mut T=mut), а НЕ return-mut-default: дефолтная mut-семантика возврата относится только к L1 binding результата у caller’а (reassign), не к pointee. У указательного типа нет «outer pointer-mut» (retracted, D216 §V2.6). -> *ro T — E_REDUNDANT_POINTER_RO (используй -> *T).

fn alloc_cell() -> *mut int                 // writable target
fn peek_head(buf []u8) -> *u8               // *u8 = ro target (D246; *ro u8 → E_REDUNDANT_POINTER_RO)
ro p *mut int = alloc_cell()                // binding ro: p фиксирован; target writable
mut q *u8 = peek_head(buf)                  // binding mut: q reassignable; target ro

Реассайнабельность результата (p = other_ptr) задаётся bind-site (ro/mut, D36), не возвращаемым типом. Это устраняет прежнюю двусмысленность «двух mut» в return-позиции (pointee-mut в типе vs reassignability указателя).

Ревизия (Plan 184, 2026-07-06). Наследование мутируемости ниже — исходная D326-R7/R8 формулировка через оракул/decay. По ревизии D326 (Plan 184, Р7) -> @ имеет конкретный тип: -> ref Self у стекового (value) типа, -> Self у кучевого — см. Ревизия D326 (Plan 184). Таблица ниже сохранена как исходная семантическая модель (поведение цепочек эквивалентно).

Особый случай: -> @ (self-return для fluent chains, D181). Возвращаемая @ наследует мутируемость от receiver:

Почему такое правило для @. @ это тот же экземпляр что receiver — его access-mutability не может быть строже, чем у receiver’а:

• ro @ receiver → @ уже view; return view’а — view; consistent.
• mut @ receiver → @ mutable handle; return mutable handle; consistent — именно так работают fluent chains xs.push(1).push(2).
• consume @ receiver → ownership уже перемещён внутрь method’а; вернуть @ = alias на consumed value = use-after-move; запрещено. Если нужно fluent после consume — возвращайте новый owned (fn T consume @transform() -> T), не @.

Что НЕ меняется в return-семантике:

• Любой явный return type (-> T, -> []u8, -> ro T, -> mut T, -> *mut T, -> *ro T) — берётся как написан (для указателей модификатор всегда относится к pointee — postfix; prefix перед * = E_POINTER_PREFIX_MODIFIER, D216 §1).
• -> Self (статический Self-тип, D182) — owned-by-caller; не наследует receiver-мут.
• -> @ без receiver-method context (free fn) → E_AT_RETURN_OUTSIDE_METHOD.

Escape hatch

Снять readonly в Nova-коде нельзя. Кому нужен mutable доступ — явно копирует: let copy []u8 = view.to_owned(). Если необходим обход через FFI, это делается в external fn на C-стороне.

Рантайм

Zero overhead — readonly только compile-time проверка, не влияет на codegen. ABI readonly []u8 = NovaArray_uint8_t* (идентично []u8).

Применение

str.as_bytes() -> readonly []u8 — zero-copy view в UTF-8 буфер строки без memcpy. UTF-8 invariant защищён: записать в буфер нельзя.

Параметры функций (Plan 108.1)

Default = read-only. Параметр без явного модификатора эквивалентен readonly param T — callee может только читать, не вызывать mut-методы, не присваивать через индекс.

fn f(b []int) { b.push(1) }       // ✗ E_PARAM_NOT_MUT — нет `mut`
fn f(mut b []int) { b.push(1) }   // ✓ explicit mut
fn f(ro b []int) { ... }    // ✓ synonym default (для документации)
fn f(consume b []int) { ... }     // ✓ owned move — mut по умолчанию

Правила сочетания модификаторов:

Coercion (передача аргумента в параметр).

После Plan 108.1 T в позиции параметра уже readonly по умолчанию. Поэтому readonly T → T (param) — это readonly → readonly (тождество), а единственное реальное нарушение это readonly → mut:

Closure-параметры — аналогично функциональным.

Закрытые маркеры (Plan 108.1)

• ✅ [M-108-readonly-mut-method-check] — вызов mut-метода на параметре без mut теперь даёт E_PARAM_NOT_MUT.
• ✅ [M-108-readonly-coerce-on-param] — closed дефакто: старая формулировка маркера предполагала, что param T mutable; после Plan 108.1 param T уже readonly, поэтому coerce readonly T → T (param) — это readonly → readonly (no violation). Единственный остаточный case — readonly T → mut T (param explicit) — отдельный followup [M-108.1-readonly-to-explicit-mut-coerce] (узкий нишевый сценарий, не блокирует).

Связь

• D36 — readonly field предшественник
• D175 — readonly field enforcement
• D144 — слайсы arr[a..b]
• D157 — view-borrow для consume-типов (Plan 108.1 распространяет принцип на не-consume)
• Plan 108 — реализация D175/D176
• Plan 108.1 — params readonly by default + закрытие 2 markers

D66. Self universal — ссылка на обобщающий тип в методах, effects, protocols

Что

Self — keyword-ссылка на «тот тип, к которому принадлежит метод», валиден в любом контексте, ассоциированном с конкретным типом:

• Внутри protocol { ... } — Self = тип, удовлетворяющий контракту (как сейчас по D42 (REVISED)/D53).
• Внутри effect { ... } — Self = тип эффекта (Db, Net, …).
• В static-методе fn T.name(...) — Self ≡ T.
• В instance-методе fn T @method(...) / fn T mut @method(...) — Self ≡ T.
• Для generic-типа T[A, B] — Self ≡ T[A, B] (с теми же параметрами).

Правило

type Box[T] {
    value T
}

// static method — Self вместо повтора Box[T]
fn Box[T].of(v T) -> Self =>
    Self { value: v }

// instance method — Self в return type для builder pattern
fn Box[T] @with_value(v T) -> Self =>
    Self { value: v }

// protocol — для type-safe equality
type Hash protocol {
    hash() -> u64
    eq(other Self) -> bool       // Self = тот тип, что реализует
}

// effect — для transactional/recursive handler-операций
type Db effect {
    query(q Sql) -> []DbRow
    nested(body fn() Self -> ()) -> ()  // Self = Db
}

// sum-type method
type Tree enum Leaf | Node(int, Tree, Tree)
fn Tree @clone() -> Self => match @ {
    Leaf          => Leaf
    Node(v, l, r) => Node(v, l.clone(), r.clone())
}

Семантика

• Self подставляется в момент использования метода/протокола, не в момент объявления.
• Для concrete-типа T (record, sum, newtype) Self ≡ T.
• Для generic T[A, B] Self ≡ T[A, B] (наследует ту же специализацию).
• Внутри protocol-объявления Self остаётся «late-bound» — конкретный тип определяется при удовлетворении.

Static-методы знают свой тип через Self

Static-метод в Nova связан с типом на уровне компилятора — не «просто функция в namespace» (как Go), а полноценный метод типа с доступом к Self. Это влияет на три use-case’а:

1. Self в return type (DRY-форма)

type Box[T] {
    value T
}

fn Box[T].of(v T) -> Self =>            // Self ≡ Box[T]
    Self { value: v }                    // generic-параметры наследуются

// Эквивалент без Self (verbose):
fn Box[T].of(v T) -> Box[T] =>
    Box[T] { value: v }

Без Self программист пишет Box[T] дважды; с Self — один раз (в receiver). Compiler знает что Self ≡ Box[T] потому что метод объявлен на Box[T].

2. Self в expression position — вызов другого статического

type Account { balance money }

fn Account.new() -> Self =>
    Self.with_initial(0)                 // другой static-метод того же типа

fn Account.with_initial(amount money) -> Self =>
    Self { balance: amount }              // Self { ... } literal

Self.with_initial(0) резолвится compiler’ом в Account.with_initial(0). То же для Self { ... } — это Account { ... } literal.

Это canonical pattern для default-конструктор → parameterized-конструктор:

fn HashMap[K, V].new() -> Self =>
    Self.with_capacity(16)              // default делегирует к parameterized

fn HashMap[K, V].with_capacity(n int) -> Self =>
    Self { buckets: new_buckets(n), count: 0, ... }

Refactoring-safe: переименование HashMap → Map меняет только заголовки методов, не тела. Все Self авто-резолвятся.

3. Self в полиморфных контекстах (через protocol bound)

type FromStr protocol {
    from_str(s str) -> Self              // late-bound
}

fn parse[T FromStr](s str) -> T => T.from_str(s)
//                                  ^^^^^^^^^^^^
// На каждой инстанциации parse[int](...) / parse[Money](...)
// T резолвится в конкретный тип. Compiler через monomorphization
// знает Self ≡ T для каждого вызова.

Это post-monomorphization — для каждого parse[X] генерится свой код где X.from_str(s) это конкретный static-метод X. Static-метод знает что он на X в каждом инстанциации.

Что это не значит

• Нет runtime-рефлексии. Static-метод не имеет cls-параметра (как Python @classmethod), не может узнать своё имя как строку, не может сравнить два типа в runtime. Знание чисто compile-time.
• Self в expression — синтаксическая подстановка. Compiler заменяет Self на имя receiver-типа в момент codegen’а; runtime никаких type-id не передаёт.
• Нет inheritance / virtual dispatch. Self ≠ виртуальный reference на subclass. У Nova нет наследования (D1) — только generic-bound через protocol.

Прецеденты

• Rust: impl Foo { fn make() -> Self { Self::new(2) } } — активно используется. Self доступен везде в impl-блоке.
• Swift: static func make() -> Self, Self.method(), Self() initializer.
• Kotlin: companion object с methods, доступ к this::class.
• C#: static метод имеет доступ к containing type.

Не следуем:

• Go: static-методов нет, только receiver-функции. Static в Nova = named function в namespace типа.
• Python @staticmethod: не получает cls, не знает свой тип. @classmethod получает cls runtime — мы делаем то же на compile-time через Self.

Где запрещено

• На top-level (вне типа/protocol/effect) — compile error «Self не в type-контексте».
• Внутри лямбды, объявленной не в method-теле — compile error.
• В сигнатуре свободной (top-level) функции fn name(...) — compile error.

Почему

1. DRY. До D66 в каждом методе fn Box[T].of(v T) -> Box[T] имя типа повторялось 2-3 раза. Refactoring (Box → Container) ломал копипастой. Self устраняет повтор.
2. Generic-параметры наследуются автоматически. fn Box[T].of с Self корректно подставит Box[T], не Box без параметров — программисту не нужно указывать generics в методе.
3. AI-friendly. LLM генерирует Self для return type без знания точного имени — снижает количество ошибок при автогенерации builder-методов.
4. Унификация. До D66 Self работало только в protocol — это создавало впечатление, что для других контекстов нужен другой механизм. На самом деле семантика одинаковая — «текущий тип». Один keyword для всех контекстов = D40 «один способ».
5. Прецеденты. Swift, Rust используют Self универсально (везде где есть impl T { ... } блок). Nova следует тому же паттерну.

Что отвергнуто

• @type — конструкция вида @type для ссылки на свой тип в методе. Отвергнуто: @ уже занят под self-field, добавление второго смысла создаёт двусмысленность.
• Имя типа повторять везде. Отвергнуто: см. п.1 «DRY».
• Self только в generic-методах (как в Java <T extends Self>). Отвергнуто: семантика остаётся та же, ограничение лишнее.

Связь

• D42 (REVISED) / D53 — Self в protocol’ах (исходное правило, расширено D66).
• 03-syntax.md → D35 — @-методы и @field.
• 04-effects.md → D61 — effect-типы и handler’ы.

Эволюция

В D42 Self был валиден только внутри protocol { ... } блока — это ограничение унаследовано от первой редакции, где Self вводился именно для type-safe equality (Hash.eq(other Self)). На practice’е Self оказался полезен также в:

• static-методах для DRY возврата того же типа,
• instance-методах для builder pattern’а,
• effect-методах для self-referential операций (transactions),
• sum-вариантах для @clone/@with_* методов.

D66 убирает ограничение: Self валиден везде, где есть type-контекст.

AMEND (Plan «self-nested-generic», 2026-06-15) — Self как вложенный generic type-arg

Правило (расширение «generic-параметры наследуются», п.2 «Почему»). Self валиден не только как самостоятельный return/param-тип, но и как type-argument внутри другого Named generic — в любой глубине вложения, в return- и в param-позиции:

type MapIter[I, T, U] value { src I, f fn(T) -> U }

// Self как вложенный type-arg — receiver-mono наследуется в позицию I
fn MapIter[I, T, U] @zmap(g fn(U) -> V) -> MapIter[Self, U, V] => ...
//                                          ^^^^^^^^^^^^^^^^^^^^ Self ≡ MapIter[I,T,U]
fn MapIter[I, T, U] @zfilter(p fn(U) -> bool) -> FilterIter[Self, U] => ...

// и в param-позиции (симметрично)
fn FilterIter[I, T] @combine(other FilterIter[Self, T]) -> ... => ...

Семантически MapIter[Self, U, V] ≡ MapIter[MapIter[I,T,U], U, V] — Self подставляется на тот же mono-инстанс receiver’а, что и в return--> Self. Это устраняет повтор имени receiver-типа в adapter-on-adapter цепочках (zero-cost ленивые итераторы, std/collections/vec_iter_zc.nv).

Где было сломано (codegen, до фикса). Call-site return-inference биндил Self value-aware (без trailing-*), но эмиссия метода (register_mono_method_instance fwd-decl + emit_monomorphized_method body) строила current_type_subst только из receiver-generics — без записи для Self. Вложенный Self промахивался мимо early-lookup current_type_subst["Self"] и падал в общий "Self"-арм type_ref_to_c, который даёт POINTER-форму (Nova_X*) → лишний trailing * → _p в mangle → C-имя mono на call-site ≠ имя в fwd-decl/body → forward-decl≠def. Это тот же класс рассинхрона, что D182 закрыл для голого -> Self.

Фикс. В обоих emit-местах после установки current_receiver_type биндить Self → value_aware_generic_c_type("Nova_{recv}*") в current_type_subst (через .entry().or_insert() — no-clobber), guard recv_type.contains("____") (только mono-инстансы). value_aware_* оставляет heap-generic / non-value формы без изменений, поэтому top-level heap-generic -> Self (где Self — owned-by-caller heap-ref, не value-record) не затронут. Подробности маркера — docs/plans/backlog-followups.md → [M-138.2-self-in-param].

Известное ограничение (НЕ покрыто фиксом). Self, равный single-param generic-ресиверу (VecIter[T]), использованный как type-arg внутри multi-param адаптера (MapIter[Self, T, U]), по-прежнему мис-резолвит receiver (chain-ENTRY методы на VecIter[T]). Фикс покрывает Self, где ресивер — тот же adapter-family, который ре-вкладывается. См. ОСТАЁТСЯ в маркере.

D72. Generic bounds через [T Protocol] — protocol как тип

Что

Параметр-тип в generic-списке может иметь bound — protocol-тип, которому должны удовлетворять конкретизации параметра. Синтаксис — единое правило «name type» без двоеточия:

[T Hash]
[K Hash, V]
[K, T From[K]]

Без bound — [T] — параметр без ограничений (структурное соответствие проверяется при использовании, как было до D72).

Bound — это protocol-тип (D53) ИЛИ type-set (D310, Plan 172.3: именованное множество конкретных типов, [T SignedInt]). Тот же Hash стоит и в позиции типа значения (fn f(x Hash) — existential), и в позиции bound’а (fn f[T Hash](x T) — universal). Одна сущность — тип со структурным контрактом — в трёх позициях:

1. Тип значения: fn f(x Hash) -> u64
2. Bound: fn f[T Hash](x T) -> u64
3. Эффект (между ) и ->): fn f(...) Db -> () (D18)

Различение по позиции, не по keyword’у. Закрывает Q-bounds.

Правило

Синтаксис

generic-params = '[' generic-param { ',' generic-param } ']'
generic-param  = identifier [ type ]

generic-param следует общему правилу Nova «name type», как параметры функции (x int), поля record (id u64), let-bindings (let x int = 5), for-loops (for x int in xs), embed (use w HashMapIter[K, V]).

fn sort[T](xs []T, less fn(T, T) -> bool) -> []T
//      ^ без bound — структурное соответствие при использовании

fn dedup[T Hash](xs []T) -> []T
//       ^^^^^^^^^^^ T должен реализовывать Hash

type HashMap[K Hash, V] {
//          ^^^^^^^^^^^ K — Hash, V — без bound
    ...
}

fn fold[T, Acc](xs Iter[T], init Acc, f fn(Acc, T) -> Acc) -> Acc
//      ^^^^^^ ни T, ни Acc bound'а не имеют

fn[T] ReceiverType @method префикс (Plan 101.1 partial, 2026-05-24)

Generic-параметры также декларируются через fn[T] префикс — для receiver’ов без carrier-brackets ([]T, bare T, tuple). Параллель D145. Bound syntax из D72 применим в этой позиции — fn[T Hash] []T @method.

fn[T] []T @map[U](f fn(T) -> U) -> []U          // T через fn[T] (нет carrier)
fn[T Hash] []T @dedup() -> []T              // bound в fn[T] (D72 + Plan 101.2)

Plan 101.1 status (2026-05-24): parser + базовый codegen работают для []int element type. Codegen mono-per-T для других element-types ([]str, []User) — marker [M-fn-prefix-int-only-mono] ✅ RESOLVED (Plan 101 Group I, vec_map_int_str fix).

Порядок объявления параметров

Generic-параметры читаются слева направо. Имя в bound’е должно быть уже объявлено — либо ранее в том же списке [...], либо в type-контексте (top-level type, окружающий тип для метода).

fn func[K, T From[K]](v K) -> T => T.from(v)
//      ^                          ^
//      объявлен раньше            используется в bound

fn func[T From[K], K](v K) -> T          // ОШИБКА: K используется до объявления
fn func[T Test[K]](v K) -> T             // ОШИБКА: K не объявлен вообще

Это согласовано с правилом параметров функции: fn f(x int, y T) — имена читаются слева направо, ранее объявленные доступны позже. Forward-references запрещены ради простоты type-checker’а и читаемости (LLM не нужно держать «отложенный контекст»).

Bound — это protocol-тип

Hash, From[T], Into[T] и т.д. — обычные protocol-типы (D53):

type Hash protocol {
    hash() -> u64
    eq(other Self) -> bool
}

// Bound в generic-объявлении:
fn map[K Hash, V](m HashMap[K, V]) -> ...

// Тот же Hash в позиции типа значения (existential):
fn dump_one(x Hash) -> u64 => x.hash()

Existential vs universal — различение по позиции:

В обоих случаях Hash — тип. Различие только в позиции: внутри [...] — generic-параметр и его bound; в обычной позиции — тип значения. Прецедент — Go (interface { M() } используется и как тип, и как constraint).

Multiple bounds — анонимный protocol

Если параметру нужно несколько bounds, объединяются в анонимный protocol-тип через protocol { ... } (D53):

fn min[T protocol { @lt(other Self) -> bool, @eq(other Self) -> bool }](xs []T) -> T

Долго, но без специального синтаксиса для intersection bound’ов. Если паттерн повторяется — выносится в именованный protocol:

type Ord protocol {
    @lt(other Self) -> bool
    @eq(other Self) -> bool
}

fn min[T Ord](xs []T) -> T => ...

Сокращённая форма [T A & B] — открытый вопрос (Q-multi-bound).

Self в bounds

Self (D66) валиден внутри protocol/method-контекста. В bound’е generic-параметра свободной функции — запрещён:

fn merge[T Eq](a T, b T) -> T => ...           // ok
fn merge[T Eq Self](a T, b T) -> T => ...      // ОШИБКА: Self вне type-контекста

В method-контексте (fn Box[T] @method[U Self]) — открытый вопрос, пока запрещено.

Bound как effect — запрещено

Bound — это protocol-тип. Effect — тоже protocol, но используется в позиции эффекта (между ) и ->). Использовать Db как bound запрещено — это ошибка категории (D62: effect ≠ protocol для generic-bound):

fn run[T Db](handler T) -> ()         // ОШИБКА: Db — effect, не bound-protocol

Если нужно «принимает Effect[Db]» — пишется явно: fn run(h Effect[Db]).

Bound на типах (не функциях)

Тот же синтаксис в declaration типов:

type HashMap[K Hash, V] {
    ro buckets []Slot[K, V]
}

type Set[T Hash] {
    ro inner HashMap[T, ()]
}

type Sorted[T Ord] | Empty | Node(T, Sorted[T], Sorted[T])

Bound применяется при инстанциировании: HashMap[User, int] требует чтобы User реализовывал Hash.

Проверка bound’а — структурная (D53)

Bound удовлетворён, если у конкретного типа есть методы из protocol’а (структурно). Никаких явных impl/declaration не нужно:

type User { id u64 }

fn User @hash() -> u64 => @id
fn User @eq(other Self) -> bool => @id == other.id

// User автоматически удовлетворяет Hash, потому что есть @hash и @eq
ro m HashMap[User, str] = HashMap.new()       // ok

Если методов нет — compile error на месте использования (HashMap[User, str] с инстанциированием), не на declaration type User.

Почему

1. Закрывает Q-bounds. Generic-инфраструктура (HashMap, From/Into, collect, FromIter) требует bound’ов. Без них либо безопасности нет, либо ошибки откладываются до места использования с непонятным сообщением.

2. Согласовано с правилом «name type». Параметр функции x int, поле id u64, generic-параметр T Hash — единая грамматика. Двоеточие в Nova зарезервировано под key-value, использовать его для bound — нарушение D17.

3. Protocol = тип (D53). Hash уже тип в Nova. Использовать его как bound — естественное расширение, не новый механизм. Existential (x Hash) и universal ([T Hash]) различаются позицией.

4. Прецедент Go. Go 1.18+: interface { M() } используется и как тип значения, и как constraint в generics. Один синтаксис, два контекста, проверено в большом продакшне.

5. Структурная проверка вместо impl. Nova не имеет orphan rule (D42/D53) — нет impl Trait for Type блоков. Bound удовлетворяется автоматически, как и existential. Это последовательно.

6. AI-friendly. LLM пишет [T Hash] без специальных keyword’ов (where, impl, :). Грамматика читается как естественный язык: «параметр T типа Hash».

Что отвергнуто

• [T: Hash] (Rust/Scala/Kotlin/Swift). Конфликтует с D17 — двоеточие в Nova только для key-value (record-литералы, dict). Делать исключение для generic-list — нарушение единства.
• [T is Hash]. is уже занят под runtime type-check (D54). Третий смысл (compile-time bound) перегружает keyword.
• where-clauses после сигнатуры (C# / Haskell-style). Многословно, раздваивает информацию между списком параметров и where-блоком. Bound у параметра — единое место.
• [T impl Hash] (Swift some-style). Нестандартно, impl не используется в Nova ни для чего ещё.
• Bounds через контракты (requires implements(T, Hash)). Контракты (D24) проверяются SMT на значениях, bound — type-checker’ом на типах. Разные уровни.
• Sealed/closed bound’ы («только эти типы»). Открытый вопрос, не входит в D72.

Цена

1. Type-checker сложнее. Проверка structural-bound при мономорфизации — дополнительная работа.
2. Сообщения об ошибках. «User не реализует Hash: missing method @hash» — нужно генерировать понятные диагностики.
3. Множественные bounds через анонимный protocol — многословно для частых пар (Hash + Eq). Сокращённая форма откладывается.

Связь

• 02-types.md → D53 — protocol = тип, основа D72.
• 02-types.md → D42 — структурная типизация, две модели generic-параметров.
• 02-types.md → D66 — Self в protocol-контексте.
• 03-syntax.md → D16 — [T] синтаксис для generic’ов.
• 04-effects.md → D18 — protocol в effect-position, отличается от bound-position.
• 08-runtime.md → D73 — From[T]/Into[T] используют bound [U From[T]] для generic-функций конверсии.
• Q-bounds — closed by D72.
• Q-collect-mechanism — становится решаемой после D72.

Открытые вопросы

• Множественные bounds: сокращённая форма ([T Hash & Eq], [T (Hash, Eq)]) — Q-multi-bound.
• Bound на эффект-параметре: можно ли [E SomeProtocolOnEffects] — связано с Q-effect-params.
• Self в bound в method-контексте — отложено.
• Conditional methods через where-clause (fn Vec[T] @sort() where T Ord) — отложено вместе с conditional impls.

Эволюция

В MVP bounds были отвергнуты (D42 «Открытые вопросы», history/rejected.md: «[T: Bound] отвергнут в MVP»). Пользовались структурным соответствием при использовании — ошибка вылезала на месте вызова, не объявления. С ростом stdlib (HashMap, From/Into, collect) стало ясно что без bound’ов нельзя: generic-функции не могут опираться на методы T без явного контракта.

Q-bounds зафиксировал синтаксис заранее ([T Bound] без двоеточия). D72 принимает это как формальное решение, расширяет до полной семантики (structural check, existential-vs-universal через позицию, multiple bounds через анонимный protocol).

⚠️ D72 AMENDED by Plan 108.4 (2026-06-09) — When a type participates as bound [T Iterable[U]] or any protocol bound, the type-checker now verifies receiver_mut consistency for all protocol methods at the use-site. A type that declares @method() (ro) does not satisfy a protocol requiring mut @method(). Errors: E_PROTO_IMPL_RO_FOR_MUT, E_PROTO_IMPL_MUT_FOR_RO, E_PROTO_IMPL_MUT_FOR_CONSUME, E_PROTO_IMPL_CONSUME_FOR_MUT. See D209.

D110. Ghost state — spec-only bindings

Статус: Принято (Plan 33.3 Ф.10, реализовано в AST и type-checker)

Решение

ghost let / ghost var объявляют spec-only переменные — они видимы в requires/ensures/invariant и других ghost-statements, но никогда не эмитируются в C-код (ни в debug, ни в release).

fn fill(xs mut []int) -> ()
    ensures forall i in 0..xs.len() : xs[i] == 0
{
    ghost ro n = xs.len()      // spec-only: виден в invariant
    for i in 0..xs.len()
        invariant forall j in 0..i : xs[j] == 0
    {
        xs[i] = 0
    }
}

Правила видимости ghost:

• Ghost-binding виден: в других ghost-stmts; в requires/ensures/invariant; в теле #pure функций.
• Использование ghost-binding в non-ghost emit-code → compile error.
• Codegen: ghost-stmts и ghost-bindings полностью стираются (паритет с Dafny).

Следствие: invariants, использующие ghost-данные, в debug не проверяются runtime — только через SMT. Это задокументированное design-решение.

Обоснование

Ghost state позволяет писать контракты в терминах вспомогательных концепций (счётчики, логические флаги, промежуточные значения), не засоряя runtime-код. Паритет с Dafny ghost var, F* Ghost.

Реализация

• compiler-codegen/src/ast/mod.rs — поле is_ghost: bool в LetDecl; enum-вариант Stmt::Ghost для ghost-блоков (Ф.10 scope).
• compiler-codegen/src/types/mod.rs — type-check: reject ghost-ref в non-ghost context.
• compiler-codegen/src/codegen/emit_c.rs — ghost-stmts стираются (пустой emit).
• compiler-codegen/src/verify/encode.rs — ghost-vars участвуют в SMT-encoding как обычные fresh-vars.

D122. Hybrid dispatch для bound-K methods

Status: active (spec). Реализация — Plan 56.

Что

Generic-bound method call’ы dispatch’аются по hybrid strategy:

1. Mono path — для concrete K на call-site (e.g. HashMap[str, int]): compiler instantiates generic method с substituted K, V. Bound methods (key.hash(), key.eq()) resolve в direct call к concrete K methods (nova_str_hash(key)). Zero-cost — паритет Rust impl<T: Hash>.

2. Erased path — для generic body emit (когда compiler не может / не должен mono’d, e.g. recursive generic call на Self type внутри generic method body): generic body эмитится как stub (call’еры полагаются на mono path для concrete instances). Bootstrap не использует vtable — простая stub-fallback стратегия.

3. Vtable path (future, Plan 56 Ф.2 full): для truly erased contexts (cross-crate generic, dyn Trait-like), bound methods dispatch’аются через vtable structure. Vtable runtime defined в compiler-codegen/nova_rt/vtables.h (Plan 56 Ф.1).

Bootstrap status (2026-05-16)

• ✅ Mono path для bound methods works (HashMap.clone() пример).
• ✅ Vtable runtime infrastructure готова (NovaVtable_Hash, NovaVtable_Compare, NovaVtable_Display + 4 primitive K vtables: int/bool/u8/f64/str).
• ✅ Erased emit для bound-method-using generic methods stub’ится (emit_generic_method_erased — wider stub condition включает Array fields с generic inner type).
• ⏸️ Vtable codegen integration (truly erased dispatch) — deferred до cross-crate compilation (Plan 03).

Acceptance criteria для bound methods

Type-checker (Plan 15 / D72) enforces:

• Bound должны быть protocol-типами (D53).
• Concrete K на call-site должен implement все bound methods (D72 enforcement).

Codegen (Plan 56 Ф.1 + Ф.2):

• Protocol-методы могут иметь эффекты (Fail / Io / Db) — напр. type TryFrom[T, E] protocol { try_from(t T) Fail[E] -> Self }. Под mono-dispatch (текущий bootstrap) эффект protocol-метода пробрасывается как у обычной effectful-функции — без спец-кейса. (D122 amended 2026-05-20: снят запрет Plan 56 Ф.2.7 на pure-only bound methods.) Ограничение: true-vtable dispatch (Plan 03) не пробрасывает effect-handlers через vtable-ABI — в truly-erased контексте effectful-protocol bounds обязаны mono-dispatch’иться; чистая vtable-диспетчеризация effectful-метода — будущая работа Plan 03.
• Self type в bound method signature substitutes runtime receiver type.

Связь

• D72 — generic bounds enforcement (type-checker side).
• D53 — protocol-типы.
• D24 — vtable lookups compatible с proven-contracts skip (no-op).

D123. Tuple monomorphization

Status: active (spec, 2026-05-17 EOD+2 — Phase 7 production polish applied). Реализация — Plan 59 (6 phases + Phase 7).

Plan 59.1 amend (2026-06-01): general generic anonymous tuple monomorphization — fn[T] f() -> (A[T], B[T]) — закрывает gap в Plan 59 Ф.7.5. Schema _NovaTuple_<arity>_<L1>_<T1>_..._<LN>_<TN> (length-prefixed) теперь применяется не только к Result, но к любому generic anonymous tuple в return position. См. D354 для full spec.

Plan 148 Ф.4 amend (2026-06-12, [M-codegen-unify-tuple-repr]): typed representation унифицирован, legacy all-int путь сжат до on-demand. Три изменения:

1. Blanket pre-decl retired. Раньше каждый C-файл получал typedef … _NovaTuple1; … _NovaTuple8; (8 all-nova_int структур) в преамбуле — вне зависимости от использования. Теперь legacy _NovaTupleN эмитится on demand только для арностей, которые erased-generic fallback реально запрашивает (на практике — только arity 2, от erased HashMap[K,V]/Set (K, V) пар). Concrete tuples всегда используют typed mono’d путь. Регистрируется через register_legacy_tuple(n), splice в /*__LEGACY_TUPLE_TYPEDEFS__*/.
2. Self-describing field decode. Field access (t.0, t.0.1) и type inference больше не зависят исключительно от per-Ident side-table tuple_element_types — элемент-тип декодируется напрямую из имени mono’d структуры в obj_ty через parse_mono_tuple_elements. Это чинит field-read на fn-параметрах, call-result кортежах и вложенных t.0.1 цепочках (раньше collapse’или в nova_int fallback → дроп второго .0 / неверный тип). Закрыло 5 pre-existing CC-FAIL в Plan 59 (f2/f10/f13/f15/f16).
3. Arity diagnostic code. Destructure-arity-mismatch diagnostic (3 codegen-сайта: let / for-pattern / match-variant inner Tuple) несёт код [E_TUPLE_DESTRUCTURE_ARITY] (раньше — bare message).

Что

Tuple типы (T1, T2, ..., TN) monomorphized — для каждой concrete комбинации element types compiler generate’ит отдельную struct с real field types (не nova_int slot erasure).

Mangle scheme (Plan 59 Phase 5, length-prefixed)

Itanium ABI / Rust v0 mangle analog — unambiguous для любой глубины nesting:

_NovaTuple_<arity>_<L1>_<T1>_<L2>_<T2>_..._<LN>_<TN>

где <Ln> — десятичная byte length sanitized name <Tn>. Parser читает length, берёт точно столько chars, переходит к следующему. Самоописательный, никаких ambiguity даже для tuple-of-tuples.

Примеры:

• (int, int) → _NovaTuple_2_8_nova_int_8_nova_int
• (str, int) → _NovaTuple_2_8_nova_str_8_nova_int
• ((int, int), int) outer → _NovaTuple_2_34__NovaTuple_2_8_nova_int_8_nova_int_8_nova_int (L1=34 — точно столько chars как T1)

Distinguishable от legacy _NovaTupleN (e.g. _NovaTuple2) по _ после NovaTuple.

Правило

ro p (str, int) = ("a", 1)
//                   ^^^^^^^ generates _NovaTuple_2_8_nova_str_8_nova_int
//                   { nova_str f0; nova_int f1; }

for (k, v) in hashmap {
//   ^^^^^^^^^^^^^^^^ implicit Iter (D58) + tuple destructure через
//                    mono'd struct (k: nova_str, v: nova_int direct
//                    field access)
}

match some_kv {
    Some((k, v)) => ...
//       ^^^^^^^ Plan 59 Phase 6 — variant payload mono'd tuple,
//               heterogeneous types работают (str + int)
}

Параллель: Rust (T1, T2) mono’d per concrete instantiation, zero-cost. C++ std::tuple<T1, T2> template — то же. Nova bootstrap паритет (vs предыдущий int-slot erasure breaking struct elements).

Decision tree

При codegen tuple type:

1. All elements concrete (resolved via current_type_subst, no type-param placeholders) → use mono’d _NovaTuple_<arity>_<L1>_<T1>... struct. Zero erasure cost.
2. Erased context (one or more element types unresolved) → fallback legacy _NovaTupleN (nova_int slot) с runtime cast. Bootstrap-compat для truly generic contexts. Plan 148 Ф.4: этот typedef эмитится on demand (per requested arity, idempotent-guarded #ifndef) — не blanket _NovaTuple1..8. На практике достигается только arity 2 (erased HashMap/Set (K, V) пары).

Constraints

• Tuple field access (p.0, p.1) — direct C field access (.f0, .f1) на mono’d struct.
• Tuple destructure (let (a, b) = ...) — direct binding, no cast.
• Nested tuples (((int, str), bool)) — recursive mono’d (inner tuple registered first; length-prefix encoding handles нестинг любой глубины — validated 5-level tests).
• Tuple в variant payload (Option[(K, V)], Result[(K, V), E]) — match destructure Some((k, v)) / Ok((k, v)) propagate mono’d element types через registry (Phase 6 + Plan 63 Fix F+).
• Tuple in collections (HashMap[K, V] returns Option[(K, V)] from iter().next()) — mono’d через template + subst at iter mono pass.

Diagnostics (Plan 59 Phase 7.1)

• Arity mismatch ([E_TUPLE_DESTRUCTURE_ARITY], code added Plan 148 Ф.4) — destructure pattern имеющий разное число элементов чем actual tuple, reject’ится Nova-level clear error (file:line + hint) до C-emit’а. Покрывает 3 sites: let-destructure, for-pattern, match-variant inner Tuple. Раньше упирался в нечитаемый “no member named ‘fN’” C error.

Lint warnings (Plan 59 Phase 7.3)

• Large tuple warning — mono’d tuple с >5 элементов OR >128 bytes estimated size emit’ит W-warning suggesting record type (clarity + stable ABI). Estimate sums known element sizes: pointers=8, nova_str=16, scalars per type. Threshold выбран эмпирически — typical cache line 64 bytes, 2× giving safe margin.

Stdlib idiom (Plan 59 Phase 7.2)

После Plan 63 Fix E (mono’d tuple iter в generic method body работает) — stdlib коллекции используют идиоматичный for (k, v) in self / for (k, v) in @iter() вместо direct-field workaround’ов. HashMap.@clone/@merge_from/@filter все idiomatic.

Field literal style (related, D52 §2)

Record literal для tuple struct полей ({ end, idx: 0 } для {end int, idx int} где end — variable в scope) — shorthand обязателен при совпадении имени поля с источником ({ end: end } запрещено, см. D52 §2).

Почему

1. Correctness — struct value types (nova_str, user records) не fit’ят в nova_int slot. Без mono (str, int) was broken.
2. Zero-cost — direct field access, no intptr_t cast, no heap alloc для tuple value.
3. Параллель Rust/C++ — индустриальный standard для tuples.
4. Diagnostics quality — Plan 36 R7 bar (file:line + hint).
5. Self-describing mangle — length-prefix encoding debug’абельно, ABI-tools (debuggers) могут decode.

Что отвергнуто (deferred с rationale)

• Universal tuple type (all elements any) — type-erased, runtime type-tag overhead, breaks AOT zero-cost goal.
• Named tuple fields ((x: T1, y: T2)) — ОТКЛОНЕНО окончательно (Plan 59 Ф.7.4, 2026-05-21). Именованные поля кортежа почти идентичны record’у; заводить два почти одинаковых синтаксиса для одной семантики в Nova нет причин. Нужен агрегат с именованными полями — это record (type T { x int, y int }). Tuple остаётся позиционным (.0/.1). ✅ REOPENED (Plan 120, 2026-05-31). Отклонение основывалось на неполном reasoning: tuple и record имеют fundamentally different allocation semantics (D32: stack vs heap). Named tuple fields не эквивалентны record — они value types с именованным доступом, zero GC overhead. See D215.
• Tuple subtyping ((int, str) <: (any, any)) — ОТКЛОНЕНО окончательно (Plan 59 Ф.7.6, 2026-05-21). Реализация дорогая (требует variance-системы covariance/contravariance в type-checker, которой в Nova нет — язык не использует structural typing); под фичу не нашлось ни одной реальной задачи. Не реализуется.
• Full mono’d Result (NovaRes_<T>_<E> typedefs analogous Option) — Plan 63 Fix F+ targeted boxed-pointer tracking покрывает все observable cases без full sum-type mono refactor. Defer до Plan 65. ✅ РЕАЛИЗОВАНО (Plan 59 Ф.7.5 increment 2, 2026-05-21): Result полностью мономорфизирован — per-(T,E) C-тип NovaRes_<ok>_<err>* (аналог NovaOpt_<T>). Legacy единый Nova_Result устранён; targeted Fix F+ boxed-tracking больше не нужен — Ok/Err payload типизируется реальным T/E inline.

Связь

• D27 — tuple литерал синтаксис.
• D52 §2 — field shorthand mandatory.
• [D58 Iter protocol] — for (k, v) in coll использует mono’d tuple через implicit .iter().
• Plan 48 — monomorphization infrastructure (mono pass).
• Plan 63 — Fix E (mono’d iter в generic method body) + Fix F/F+ (Result Ok payload tuple unboxing).

D215. Named tuple fields + value/reference allocation contract

Status: active (spec, 2026-05-31). Реализация — Plan 120. Extends D52 tuple form; amends D32 с explicit value/reference taxonomy; amends D123 с named field codegen. Withdraws Plan 59 Ф.7.4 rejection (corrected reasoning).

Что

Extension D52 tuple form: поля кортежа могут быть именованными (parallel с positional). Named tuple — stack-allocated value type с именованным доступом (.x, .y), identical performance к positional tuple (D123).

Allocation contract — bracket choice кодирует semantics:

Синтаксис

// Named tuple declarations
type Point(x f64, y f64)
type Vec3(x f64, y f64, z f64)
type Color(r u8, g u8, b u8, a u8)
type Generic[T](value T, count int)

// Construction — named args
ro v = Vec3(x: 1.0, y: 2.0, z: 3.0)
ro c = Color(r: 255, g: 0, b: 128, a: 255)

// Field access — by name
v.x     // 1.0
v.y     // 2.0

// Methods — identical to records
fn Vec3 @add(other Vec3) -> Vec3 =>
    Vec3(x: @x + other.x, y: @y + other.y, z: @z + other.z)

Грамматика (extends D52)

tuple_fields  ::= positional_list | named_list
positional_list ::= type ("," type)*
named_list      ::= named_field ("," named_field)*
named_field     ::= IDENT type

// Mixed positional+named в одном декларации — forbidden (E_TUPLE_MIXED_FIELDS)

Parser disambiguation: если после ( стоит IDENT type-start → named tuple; иначе → positional. Один lookahead, никакого backtracking.

Type errors

Codegen (extends D123)

Named tuple → C named struct (not anonymous):

typedef struct NovaTuple_Vec3 NovaTuple_Vec3;
struct NovaTuple_Vec3 {
    double x;
    double y;
    double z;
};

Symbol prefix NovaTuple_<Name> distinguishes от positional _NovaTuple_<arity>_... и от records Nova_<Name>*. Named tuple = value type (no pointer in C signature); всегда stack-allocated.

Method receiver passing (Plan 128 Ф.2, 2026-06-05)

Named tuple @-методы получают receiver через ABI-conditional форму:

Mutation visibility: mut @method мутирует caller’s slot через pointer; copies стека не делается. Это symmetric с D228 value-record mut @method (NovaValue_X*).

Call-site emission (emit_c.rs::prepare_method_recv):

• Identifier receiver: emit &local_var directly. Var must be mut binding (D33 + D215 amend «binding-level mutability»); ro binding + mut @method = E_BINDING_NOT_MUT (caught в type-checker).
• Lvalue projection receivers: b.v.method(), arr[i].method(), @field.method(), multi-level a.b.c.method() — when each base в projection chain is an lvalue (Ident/SelfAccess/Member-of-lvalue/ Index-of-lvalue), emit &(b->v) / &(arr->data[i]) / &(nova_self->field) directly. Mutation flows к original slot, no temp hoist. Plan 128.1 Ф.1 implementation.
• Rvalue receiver: hoist в NovaTuple_<Name> __tmp_recv_<id> = expr; и pass &__tmp_recv_<id>. Мутации в temp видны только внутри expression chain — corresponds к D32 «mutate-by-copy для rvalue» spirit.
• Chained .method() на trailing receiver — recurse same rule.

Symmetric правило с records (D32): records передаются Nova_<Name>* unconditionally; named tuples — by-value кроме mut @ receiver path, который промоутится к NovaTuple_<Name>*. Это codifies «no pointer in C signature кроме mut receiver» refinement над D215 original wording.

Wired через recv.mutable flag (MethodCallInfo::recv) — Plan 128 Ф.1 thread’нул flag через emit_c.rs helpers; Ф.2 consume’нул для NamedTuple codegen branch. См. также §D228 Ф.4 «Method receiver passing» — параллельный pointer pattern для value-records.

Use cases (recommended patterns)

Почему: Plan 59 Ф.7.4 rejection был неполным

Plan 59 rejection (2026-05-21) argued: «named tuples ≈ records, нет причин иметь два похожих синтаксиса». Reasoning flaw: tuple и record имеют fundamentally different allocation semantics:

• Tuple → stack, zero GC pressure, copy semantics
• Record → heap (D32, D123), GC-tracked, reference semantics

Разные allocation characteristics = разные performance + lifetime characteristics = different syntactic forms justified. Plan 120 (2026-05-31) reopens с corrected reasoning.

Out of scope (followups)

• [M-120-positional-fallback]: allow .0/.1 на named tuples (Rust-style fallback). V1 = Option B: forbid (Q120 decision).
• [M-120-named-positional-mix]: mixed positional+named в одном decl.
• [M-120-stack-arrays]: stack-allocated fixed-size arrays [3]Vec3.

Связь

• D32 — value vs reference taxonomy (amended)
• D52 — tuple syntax (amended + named form)
• D123 — positional tuple codegen (named form extends)
• Plan 120 — реализация

D354. Generic anonymous tuple monomorphization

Renumber 2026-07-03: блок был D216 — номер коллидировал с D216 Typed pointer family; anon-tuple-mono перенумерован в D354 (решение владельца; приёмник из резерва Plan 174 §6, прецедент D109/D110/D111). Status: active (spec, 2026-06-01). Реализация — Plan 59.1. Extends D123 с generic-aware substitution path. Closes gap в Plan 59 Ф.7.5 (Result mono landed; general generic anonymous tuple оставался под V1 erasure fallback до 2026-06-01).

Что

Generic anonymous tuple в return position функции с type-параметрами — fn[T] f() -> (A[T], B[T]) или fn[T, U] g() -> (T, U) — мономорфизируется per instantiation. Element types конкретизируются через current_type_subst, получают C-name через type_ref_to_c, регистрируются через register_mono_tuple, и emit’ятся как unique typedef’ы per element combination.

fn[T] dup(v T) -> (T, T) => (v, v)

test {
    ro (a, b) = dup[int](42)           // → _NovaTuple_2_8_nova_int_8_nova_int
    ro (s, t) = dup[str]("hi")          // → _NovaTuple_2_8_nova_str_8_nova_str
    // Два разных typedef'а в одной compilation unit, каждый с real types.
}

fn[T, U] pair(a T, b U) -> (T, U) => (a, b)
ro (i, s) = pair[int, str](7, "x")      // → _NovaTuple_2_8_nova_int_8_nova_str

Правило

Mangling schema

Length-prefixed mangling: _NovaTuple_<arity>_<L1>_<T1>_<L2>_<T2>...

• <arity> — количество элементов
• <Li> — длина sanitized C-name i-го элемента
• <Ti> — sanitized C-name (точки/звёздочки заменены на _, pointer suffix retained как _p)

Примеры:

• (int, int) → _NovaTuple_2_8_nova_int_8_nova_int
• (str, bool) → _NovaTuple_2_8_nova_str_9_nova_bool
• (ChanWriter[T], ChanReader[T]) после mono[T=int] → _NovaTuple_2_18_Nova_ChanWriter_p_18_Nova_ChanReader_p

Length prefix обязателен — без него parsing неоднозначен для nested tuples (tuple of tuples) и user types с underscores в имени.

Per-instantiation deduplication

mono_tuple_instances (HashSet) хранит set element-type vectors. register_mono_tuple([elem1, elem2, ...]) идемпотентен — повторные вызовы с same elements не emit’ят дубликаты typedef’а.

Finalize emit (typedef ordering)

В module finalize все registered tuples emit’ятся с topological sort’ом (внутренний tuple раньше outer’а):

• Tuple A depends on tuple B если B’s mangled name появляется как element type в A → emit B first.
• Cycle detection: impossible для value-tuple struct’ов; если обнаружен — emit anyway без depth-check (no hang).

Codegen в emit_call

1. Call-site f[T1, T2, ...](args) lookups mono_fn_decls[f.name].
2. resolve_mono_type_args строит type_subst из turbofish + arg-inference.
3. compute_mono_name(base, subst) → unique mono fn name.
4. register_mono_instance enqueue в worklist.
5. Args emit без erasure boxing (concrete types).
6. Variable type at call site = mono’d tuple via type_ref_to_c(return_type) с активным current_type_subst.

Body emission (emit_monomorphized_fn)

current_type_subst устанавливается перед body emit; type_ref_to_c(TypeRef::Tuple) возвращает mono’d name; tuple-литералы emit’ятся как value-struct compound literals (no heap-box).

Destructure

emit_tuple_destructure использует actual mono’d return type для temp variable (получает через infer_expr_c_type). Element types парсятся через parse_mono_tuple_elements (length-prefixed inverse). Arity mismatch → Nova-level diagnostic с pattern/scrutinee arity (Plan 59 Ф.7.1).

Value semantics, no heap-box

Mono’d tuple — value type (C struct), passed by value, returned by value. No heap allocation для anonymous tuple wrapper’а (Result mono Ф.7.5 parity). Element pointers (если elements — pointer types) остаются heap-allocated независимо.

Edge cases (covered V1)

• ✅ Multi-instantiation: same fn → разные T → unique typedef’ы per instantiation.
• ✅ Multi-param tuple: fn[T, U] pair(a T, b U) -> (T, U).
• ✅ Nested generic tuple: fn[T] nest() -> (T, (T, T)) — recursive subst через register_tuples_in_typeref.
• ✅ Tuple-in-Option: fn[T] f() -> Option[(T, T)] — Option mono + inner tuple mono.
• ✅ Tuple-in-Result: уже работает (Plan 59 Ф.7.5).
• ✅ Non-generic tuple: fn make() -> (int, str) — без T, substitution тривиален, мономорфизация single instance.
• ✅ Arity 3+: fn[T] triple() -> (T, T, T) — generic mangling параметризован по arity.
• ✅ Positional field access: pair.0 / pair.1 после mono.

Edge cases (V1 limitations — followups)

• 🟡 [M-59.1-array-of-mono-tuple]: fn[T] f() -> []((T, T)) — array-of-mono-tuple. Body falls back на NovaArray_nova_int* (boxed pointer storage, как records/sums в bootstrap), call-site infer выдаёт NovaArray_<mono_tuple>* (typedef которого не существует). Mismatch → CC-FAIL. Fix: align infer с body fallback ИЛИ packed NovaArray_<mono_tuple> typedef + element retrieval cast. Низкий приоритет — workaround через explicit Nova_ record type.

  Update 2026-06-08 (Plan 91 Ф.1, [M-91.1-composite-array-storage]): Для pointer-элементов (record/sum Nova_<Name>*) этот класс РЕШЁН выбранным здесь подходом «align infer с body fallback» + завершением side-channel array_element_types. Контракт хранения composite-массивов: элементы record/sum — boxed-pointer в nova_int слоте (NovaArray_nova_int*), а реальный elem C-тип проносится через array_element_types (var→Nova_<X>*) и проставляется на результат generic map/filter (register_array_result_elem), так что [i], for-in и .get() кастят слот назад к указателю. Tuple-by-value ([]((T,T)) — value-struct >8 байт) НЕ покрыт erasure-подходом и остаётся открытым как [M-91.1-value-struct-array-elem] (тот же класс, что и []Option[T]). Подробности — plan-91 Ф.1 closure.

• 🟡 [M-59.1-tuple-field-oob-nova-diag]: pair.5 на arity-2 tuple leaks к C-level error «no member named ‘f5’». Should be Nova-level diagnostic в type-checker. Cosmetic — error caught, но not optimal UX.

• 🟡 [M-59.1-channel-new-cleanup]: Channel.new продолжает использовать 3 ad-hoc special-case branches в emit_c.rs:18435/20159/22694 + Nova_ChannelPair runtime struct. После Plan 59.1 generic mono path способен обработать Channel.new если добавить Nova-side declaration fn[T] Channel[T].new(cap int) -> (ChanWriter[T], ChanReader[T]) через external fn (Plan 115 Pattern B). Cleanup deferred to отдельный план (runtime + std API surgery). Spec D91 signature остаётся буквальной реальностью после cleanup’а; до того — implementation detail, aspirational notation.

Backward compatibility

• Все existing non-generic anonymous tuple usages ((int, str) returns, destructures) — продолжают работать unchanged. Plan 59 Ф.7.5 mono’d path был активен только для Result; теперь активен для всех anonymous tuples.
• Plan 59 Ф.7 legacy _NovaTuple<arity> schema (без underscore — nova_int placeholders) технически остаётся как fallback в type_ref_to_c для cases где type_subst не доступен (degenerate case — non-generic context с unresolved tuple). На практике не наблюдается после fix.

Cross-refs

• D52 — anonymous tuple type syntax.
• D123 — positional tuple codegen baseline (Plan 59 Ф.7.5).
• D215 — named tuple types (Plan 120 D215, ortho к D354).
• D91 — Channel.new signature now буквально implementable; cleanup ad-hoc paths — [M-59.1-channel-new-cleanup].
• D141 — bulk slice-операции (orthogonal к tuple mono).
• Plan 59.1 — implementation plan.
• Plan 59 Ф.7.5 — Result mono prior art.

D119. Method-level type parameters в generic methods

Status: active (spec, 2026-05-17). Реализация — Plan 48 Ф.9. Закрывает частично Q-generic-receiver-method (для user-defined generic типов; built-in []T остаётся V2).

Что

Generic methods могут иметь собственные type-параметры, независимые от type-параметров receiver’а. Метод Wrapper[T] @map[U](f fn(T) -> U) -> Wrapper[U] имеет два уровня generics: receiver-level T и method-level U. Compiler через monomorphization создаёт отдельную mono-instance для каждой комбинации (T, U).

Правило

export type Wrapper[T] { inner T }

// Receiver-level T, method-level U.
export fn Wrapper[T] @map[U](f fn(T) -> U) -> Wrapper[U] {
    Wrapper[U].of(f(@inner))
}

// Call-site:
ro w = Wrapper[int].of(5)
ro a = w.map(|x| x * 2)              // (T=int, U=int) instance
ro s = w.map(|x| str.from(x))        // (T=int, U=str) instance
ro s2 = s.map(|x| x + "!")           // (T=str, U=str) instance

Compiler emits 3 distinct mono’d methods:

• Wrapper____nova_int_method_map____nova_int
• Wrapper____nova_int_method_map____nova_str
• Wrapper____nova_str_method_map____nova_str

Параллель: Rust impl<T> Wrapper<T> { fn map<U>(self, f: impl Fn(T) -> U) -> Wrapper<U> } — то же monomorphization per (T, U). C++ template<T> class Wrapper { template<U> Wrapper<U> map(...) } — то же. Nova bootstrap теперь паритет.

Decision tree

При codegen call’а obj.method[U](args):

1. Receiver T — резолвится из obj C-type (Nova_Wrapper____<T>* → T = <T>). Существующая infrastructure (D72 + Plan 48 Ф.0).
2. Method-level U — резолвится через bidirectional inference из call args:
   • Non-closure args: infer_expr_c_type(arg) → bind U через infer_type_param_binding.
   • Closure-typed args (|x| body): pre-populate closure-param types с T-substituted C-types, recurse в body для return type → bind U.
3. Method C-name включает обa уровней: <TypeBase>____<T>_method_<m>____<U>.

Constraints

• Method-level generics declared в @method[U] — synтаксис как у free-function generics (fn name[U](...)); receiver [T] parsed отдельно.

• Closure args drive inference — без explicit turbofish (obj.map::<int>(...)), U inferенtsя из closure return type. Если нет args или U не появляется в parameter types, compiler emit’ит clean diagnostic:

  cannot infer method-level type argument `U` for generic method
  `<TypeBase>____<T>.<method>` (only in return type — provide arg
  whose type binds it); provide a closure/arg whose type fixes `U`
  

  (См. реализацию в compiler-codegen/src/codegen/emit_c.rs path 5b.) Раньше unresolved method-level params silently dropped → Nova_U_p placeholder leak в emitted C → undefined-struct CC-FAIL.

• Per-(T, U) instances — каждая уникальная пара получает свою mono’d function. Worklist enrollment предотвращает дубликаты.

• Return type substitution — Wrapper[U] в return type корректно resolves в Nova_Wrapper____<U>* (не Nova_U_p placeholder).

Почему

1. Параллель Rust/C++ — индустриальный standard для generic methods.
2. Zero-cost — каждая mono-instance это direct call, инлайнится, no void* boxing/cast.
3. Composability — w.map(f).map(g).filter(p) typical functional chain работает без erasure penalty.
4. Был CC-FAIL — без method-param mono let m = w.map(|x| str.from(x)) эмиттил Nova_Wrapper____Nova_U_p* m = ... (undefined struct, C-compile fail).

Что отвергнуто

• Method-level type-erasure (void* U) — для bootstrap проще, но ломает первый-class closures + breaks struct-typed U (record-value не fit’ит в void* без heap-box). Equivalent проблема к Plan 48 receiver-level erasure отвергнутой в V1.
• Explicit-only U (obj.map::<U>(...) обязателен) — verbose, не matches industry standard. Inference из args — first-class.

Связь

• D72 — generic bounds на type params; method-level U могут иметь bounds.
• D122 — hybrid dispatch для protocol-bound type params; orthogonal к method-level vs receiver-level.
• D123 — tuple mono пользуется тем же worklist infrastructure.
• Plan 48 Ф.9 — реализация (emit_call path 5b + infer_mono_method_ret_with_args).
• Plan 63 Fix C — remaining edge case Plan 63, закрытый этим D119.
• Q-generic-receiver-method

D367. Удаление byte: каноническое имя — u8

Решение: Тип byte удалён из языка. Единственное каноническое имя для 8-битного беззнакового целого — u8. Срез байт пишется []u8.

Мотивация. Наличие двух равнозначных имён (byte и u8) порождает неоднозначность в коде, документации и стандартной библиотеке: один и тот же тип можно было написать двумя способами, что усложняло чтение и тулинг.

Миграция. Все вхождения byte как типа заменяются на u8:

• []byte → []u8
• параметры/поля типа byte → u8
• в примитивном перечислении: byte убирается из списка

Исключения (не меняются):

• Тег шаблонных строк bytes`...` (D48) — это имя функции, не тип.
• Слово «byte» в английском/русском тексте комментариев (единицы памяти).

Реализовано: Plan 69 — 2026-05-22. byte удалён из builtin-типов компилятора (lexer/parser/type-checker/ codegen); все вхождения в spec/ / std/ / nova_tests/ мигрированы на u8. C-typedef nova_byte (= uint8_t) сохранён как внутреннее имя codegen — не пользовательская поверхность.

D368. Strict type propagation в codegen — no silent nova_int fallback

Решение. Codegen pass (compiler-codegen/src/codegen/) обязан производить deterministic, явный C-type для каждого Nova expression и type reference. Silent fallback к nova_int при failure type resolution — запрещён. Любой site где type_ref_to_c(...) возвращает Err без strict-error должен производить compile-time diagnostic [E7001] и failing build, а не подставлять placeholder type.

Мотивация. До Plan 70 паттерн type_ref_to_c(&ty).unwrap_or_else(|_| "nova_int".into()) встречался в codegen в 117 местах (audit 2026-05-18). Семантика: «если type translation failed → silently emit nova_int (long long) и продолжай». Результат — silent miscompilation:

• pointer cast to int → garbage address как число
• bool/char печатается как code-point (Plan 67 закрыл частный случай)
• record/sum-type memcpy с неправильным sizeof
• float → int truncation

Программа «работает», но возвращает мусор. Debug невозможен — компилятор ничего не сигналит.

Industry baseline. Rust / Swift / Go (post-1.18) — все производят compile error на любом unresolved type в codegen. Nova до Plan 70 был хуже всех baseline (silent default). D368 закрывает регрессию.

Категории erasure (Cat A/B/C/D). Audit разделил 154 fallback sites на четыре категории:

Только Cat A даёт silent miscompilation. После Plan 70 closure все Cat A sites мигрированы к strict error path. Cat B/C/D documented в docs/codegen-erasure-sites.md.

Strict-error architecture. Две helper-функции в emit_c.rs:

1. err_no_int_fallback(context, cause) → String — для functions возвращающих Result<_, String>. Используется с ? propagation:

   let ty = self.type_ref_to_c(&p.ty).map_err(|e|
       self.err_no_int_fallback("parameter `x`", &e)
   )?;
   

2. record_strict_error(context, cause) → "nova_int" — для cascade-blocked sites (functions whose signature нельзя менять без massive caller-chain refactor: infer_expr_c_type (135 callers), register_mono_instance, etc). Pushes E7001 в strict_errors: RefCell<Vec<String>> field; finalization gate в emit_module проверяет non-empty и failit codegen pass с aggregated error message.

Оба helper’а используют unified diagnostic format [E7001] (range E7001-E7099 reserved для Plan 70 family). Plan 36 R7 structured diagnostic compatibility.

Production-grade default. Strict mode — always on, без opt-in env var. ANY silent fallback = build failure (Rust/Swift baseline). Это breaking change для user code который полагался на silent int default (R20 в Plan 70). Bootstrap convention: clean break с machine-applicable migration suggestions.

Diagnostic format (E7001).

[E7001] cannot infer C type for parameter `x`: <cause>. Silent
fallback к `nova_int` produced wrong runtime output для non-int
types (record/string/float/bool). Add explicit type annotation,
ensure generic is monomorphized, или register type в external_registry.
См. Plan 70 ([M-no-silent-nova-int-fallback]).

Internal lint guard (CI). scripts/lint-no-silent-int-fallback.sh greps compiler-codegen/src/ против baseline counts из docs/codegen-erasure-sites.md. Bumping baseline требует:

1. Inline comment с rationale «почему erasure безопасна»
2. Entry в docs/codegen-erasure-sites.md со file:line + причина
3. PR review

CI gate fails если added counts превышают baseline без updates.

Acceptance criteria (Plan 70 closure).

• Helper infra err_no_int_fallback + record_strict_error (Ф.1 / Ф.B0)
• Cat A1/A2 migration: 90 → 8 (only Cat B holdovers remain)
• Cat B documentation: 10 sites listed в codegen-erasure-sites.md
• Internal lint guard scripts/lint-no-silent-int-fallback.sh
• Spec D368 (этот блок)
• 796+ PASS / 0 FAIL nova test (0 regressions vs baseline 761)

Реализовано: Plan 70 — sessions 1+2 (2026-05-18); 90+ Cat A1 sites migrated, infrastructure complete, lint guard active.

Связь:

• D118 — typed Fail[E] codegen (similar precision-by-construction pattern)
• Plan 67 — println overload fix (sibling: один из видимых частных случаев)
• Plan 48 — monomorphization (упрощает Cat B → меньше erasure)
• Plan 36 — diagnostic infra (R7 structured format)
• docs/codegen-erasure-sites.md — Cat B/D inventory

D128. char distinct from int в codegen mono’d generics

AMEND (Plan 152.8, 2026-06-16). nova_char переведён с int64_t на uint32_t. Codepoints fit in 21 bits (U+0000..U+10FFFF); uint32_t — естественный unsigned type (как Rust char ABI). ABI cost минимален: nova_char-поля в structs layout’ятся как 4-byte, Box-pointer смещается с 8 на 8 (4-byte char + 4-byte padding → align 8). GC layout обновлён: char_size = (4, 4) (было (8, 8)). Char-literal суффикс: U вместо LL; is_typed_int_c_ty / emit_typed_int_literal включают nova_char.

Решение (исходное, Plan 70.3). Тип char имеет собственный C-typedef nova_char (alias над int64_t → uint32_t D128 AMEND), distinct C identifier). Generic mono mangling использует nova_char separately от nova_int, поэтому Option[char] и Option[int] производят разные C-типы NovaOpt_nova_char vs NovaOpt_nova_int — структурно неотличимы становятся различимы.

Мотивация. До Plan 70.3 оба char и int map’ились в один C-тип nova_int. Результат — silent type collapse в generic mono:

• Option[char] и Option[int] mangle в идентичный NovaOpt_nova_int
• []char и []int обе → NovaArray_nova_int*
• Map[char, V] и Map[int, V] → одинаковая mangled name

Concrete observed bug (триггер плана): str @char_at(idx int) -> Option[int] declared, returned Option[char] де-факто. Type-checker не ловил поскольку C-level structural compatibility. ~50 callers использовали char literals (Some('/'), unwrap_or('.')) в slot expecting Option[int] — silent collapse через NovaOpt_nova_int. User pre-fix 2026-05-19 corrected signature, Plan 70.3 — архитектурное предотвращение.

Industry baseline. Rust/Swift char is distinct primitive (char vs u32); Go has rune distinct from int32. Nova до Plan 70.3 был unusual в C-level collapse. D128 закрывает регрессию.

Implementation (Plan 70.3 Ф.1-Ф.2).

1. Typedef: typedef int64_t nova_char; → typedef uint32_t nova_char; (D128 AMEND Plan 152.8) в compiler-codegen/nova_rt/nova_rt.h.
2. Codegen mapping: type_ref_to_c "char" => "nova_char" (was "nova_int") в emit_c.rs и external_registry.rs (двойная sync).
3. Array element: []char → NovaArray_nova_char* (separate instantiation parallel NovaArray_nova_int*).
4. Option element: NovaOpt_nova_char typedef + constructors + nova_opt_eq_nova_char helper.
5. CharLit emission: 'x' → ((nova_char)<codepoint>U) (was LL; D128 AMEND Plan 152.8 — uint32_t requires U-suffix).
6. infer_expr_c_type: CharLit => "nova_char" (was "nova_int").
7. Runtime fn signatures: nova_str_char_at updated return NovaOpt_nova_char (was NovaOpt_nova_int).

GC layout (D128 AMEND Plan 152.8). char_size = (4, 4) (was (8, 8)). In a struct with a char field followed by a Box pointer: char occupies 4 bytes + 4-byte pad → Box at offset 8. gc_layout.rs::prim_emit("char") => Some((4, 4)).

Backward compat. В emit_binary_op special-case для Nova_StringBuilder* + char accepts обе nova_char AND nova_int для backward-compat — pre-fix existing code emitted char as nova_int, existing test binaries reference legacy form. After full migration of existing generated C (regen test fixtures), nova_int branch может быть удалён.

ABI cost. Minimal. nova_char is typedef uint32_t — 4 bytes vs 8 bytes. Struct layout changes where char is followed by a pointer (padding shrinks from 0 to 4 bytes). GC scanner updated. C type identifier remains distinct from nova_int.

Acceptance criteria.

• Ф.1 codegen mapping switch (emit_c.rs + external_registry.rs)
• Ф.2 runtime helpers parallel (NovaArray_DECL(nova_char), NovaOpt_nova_char constructors + eq helper)
• Ф.3 audit + fixtures (2 PASS в nova_tests/plan70_3/)
• Ф.4 type-checker tightening (reject let x Option[int] = Some('a'))
• Ф.5 spec D128 (этот блок)
• 0 regressions в nova test (801 PASS sustained)

Реализовано: Plan 70.3 — Ф.0-Ф.5 closed 2026-05-19. D128 AMEND (Plan 152.8) — nova_char int64_t→uint32_t, 2026-06-16.

Связь:

• D26 — Q-string-indexing (char = codepoint convention)
• D54 — as-cast narrowing (explicit char↔int conversion)
• Plan 70 — parent family (silent type bugs от Nova↔C collapse)
• Plan 70.4 — sibling proposal (f32/f64 generic-container distinct mangling)

D129. int как alias i64 в bootstrap Nova

⚠️ AMEND (Plan 133) — ЧИТАЙ ПЕРВЫМ: int = intptr_t, НЕ int64_t

int = nova_int = intptr_t — ЗНАКОВОЕ ADDRESS-SIZED ЦЕЛОЕ (модель Go C-эры intgo), а НЕ int64_t.

• int → nova_int (typedef intptr_t) — ширина = ширине указателя платформы (64 бита на x86_64/ARM64, 32 бита на 32-bit/WASM). См. nova_rt.h: typedef intptr_t nova_int; /* int — signed address-sized (Go C-era intgo, Plan 133) */.
• i64 → int64_t — ВСЕГДА ровно 64 бита, независимо от платформы.
• На bootstrap-таргете (x86_64, 64-битный указатель) int и i64 СОВПАДАЮТ по ширине и значению — отсюда историческое слово «alias» в заголовке/теле ниже — НО это РАЗНЫЕ C-типы: primitive_name_to_c даёт int → nova_int и i64 → int64_t, поэтому их mangle-имена РАЗЛИЧАЮТСЯ (NovaOpt_nova_int ≠ NovaOpt_int64_t; Map[int,V] ≠ Map[i64,V] по C-имени).
• «int ≡ i64» — совпадение ШИРИНЫ на 64-бит, НЕ тождество типов. Не считать int равным i64/int64: аналогия — Go int ≠ int64, Rust isize ≠ i64 (platform-pointer-width). На 32-bit/WASM int станет 32-битным, i64 останется 64-битным.
• Следствие для §0/named-priority: числовая константа/выражение типа i64 НЕ должна схлопываться в nova_int (и наоборот) — это разные типы (см. Plan 172.1 P67 ФАЗА 2 STEP 1, де-коллапс i64.MAX→int64_t). То же char (codepoint, nova_char) ≠ int.

Текст «Решение / Мотивация / Codegen» НИЖЕ — ИСТОРИЧЕСКИЙ (Plan 70.4, до Plan 133): его утверждения «оба → nova_int (typedef int64_t)» и «mangle идентичен» УСТАРЕЛИ — читать как «совпадают по ширине на 64-bit», а C-тип nova_int теперь intptr_t, не int64_t.

Решение. Тип int в Nova bootstrap является alias для i64 (64-bit signed integer) ПО ШИРИНЕ/ЗНАЧЕНИЮ на 64-bit таргете (см. ⚠️ AMEND выше — C-типы РАЗНЫЕ: int→nova_int=intptr_t, i64→int64_t). Оба маппируются в C-тип nova_int (typedef int64_t) [УСТАРЕЛО Plan 133]. Отсутствие distinction в codegen намеренно относится к bootstrap-x86_64 (где ширины совпадают), но int и i64 — различимые типы (разный C-typedef, разный mangle): это не collapse-баг, а address-sized vs fixed-width архитектурное различие (Plan 133).

Мотивация. Audit Plan 70.4 выявил, что int и i64 используют один C-тип. Mangle для Map[int, V] и Map[i64, V] идентичен. В отличие от других collapse-паттернов Ф.1/Ф.2 плана 70.4 (ABI-real silent miscompilation) или Plan 70.3 char/int (semantically distinct types), int ≡ i64 является семантическим инвариантом — оба означают 64-bit signed integer без разницы в значении или поведении. Nova bootstrap targets x86_64 only (fixed 64-bit pointer width).

Industry baseline.

• Rust: isize distinct от i64 (platform-pointer width varies на 32-bit)
• Go: int distinct от int64 (platform-pointer width)
• C#: int = alias System.Int32 (semantically identical)
• Python/Java: нет fixed-width integer aliases
• Nova: int = alias i64 — правильная аналогия C# для fixed-width platform

Future evolution path. Если Nova добавит multi-arch targets (32-bit, WASM), int может стать platform-pointer-width type аналогично Rust’s isize. На этот момент потребуется breaking change в codegen mangling — Map[int, V] и Map[i64, V] станут distinct. D129 explicitly documents текущее bootstrap decision как alias-based, чтобы будущий architect не принял отсутствие distinction за bug. Migration path: introduce nova_iptr (platform-width) typedef, make int resolve to it, maintain nova_int = int64_t for i64.

Codegen. Без изменений. type_ref_to_c "int" => "nova_int" и "i64" => "nova_int" — оба корректны и эквивалентны по спецификации. Distinct mangling не вводится, т.к. это создало бы необходимость явно выбирать int vs i64 для каждого generic instantiation — user-hostile и ортогонально семантической разнице (которой нет).

Acceptance criteria.

• Ф.3 spec D129 (этот блок) — формализует alias decision
• Нет codegen изменений — intentional collapse документирован
• Future: multi-arch migration path зафиксирован (Migration note выше)

Реализовано: Plan 70.4 — Ф.3 closed 2026-05-19.

Связь:

• D54 — as-cast narrowing semantics
• D128 — Plan 70.3 char/int distinction (contrast: там distinction нужна)
• Plan 70.4 — parent plan (этот блок = Plan 70.4 Ф.3)
• Plan 70 — parent family (silent type bugs)

D130. uint — unsigned 64-bit alias в bootstrap Nova

AMEND (Plan 133). C-тип uint — nova_uint (typedef uintptr_t, address-sized unsigned), а не сырой uint64_t. На x86_64-bootstrap (фикс. 64-бит указатель) nova_uint ≡ uint64_t по ширине/знаку; u64 остаётся фиксированным uint64_t. Канонический словарь — primitive_name_to_c (uint → nova_uint).

AMEND (Plan 172.1-K1, 2026-06-28). uint (и вся РАЗЛИЧНАЯ int-семья) лоуэрится в свой точный C-тип во ВСЕХ позициях — включая method-receiver. Ранее receiver_c_type схлопывал примитивный ресивер (uint/u8..u64/i8..i32) в nova_int (Plan 70.5 «64-бит слот») — нарушение §0/§10/D368 (второе окно правды) и soundness-баг: Nova_uint_method_compare(nova_int, nova_int) давал знаковое сравнение беззнаковых (неверный порядок для uint с установленным старшим битом). Теперь scalar-arm receiver_c_type делегирует в единый primitive_name_to_c (тот же лист, что resolved_type_to_c): uint-ресивер = nova_uint → @-операции беззнаковые ПО ПОСТРОЕНИЮ. int≡i64→nova_int сохраняется (D129 — намеренный alias, НЕ схлопывание различных типов). Acceptance: spec_tests/conformance/d130_uint_method_compare.nv. receiver_c_type как отдельная функция ретайрится в receiver-aware resolved_type_to_c (U.4.5/FIN).

Решение. Тип uint является alias для u64 (64-bit unsigned integer) в Nova bootstrap. Маппируется в C-тип uint64_t (AMEND Plan 133: → nova_uint). Отличие от int/i64 (alias pair, signed) — uint/u64 является симметричным unsigned pair. int as uint cast saturates (negative → 0); int as u64 — direct bit-cast (существующее поведение сохранено).

Дизайн (Q1-Q4, подтверждены 2026-05-19).

Saturation semantics (int as uint).

 -1000 as uint → 0
    -1 as uint → 0
     0 as uint → 0
     1 as uint → 1

Реализован через nova_int_to_uint(int64_t x) helper в nova_rt/cast.h. u64 as uint — direct cast (no-op; uint64_t → uint64_t).

Codegen mapping.

• type_ref_to_c "uint" => "uint64_t" (scalar)
• []uint → NovaArray_uint64_t* (parallel с u64)
• Option[uint] → NovaOpt_uint64_t (parallel с u64)
• uint.MAX — не поддержан parser’ом (parser не распознаёт uint как type-path prefix; используй u64.MAX = эквивалент).

Будущая эволюция. Аналогично D129 (int/i64): если Nova добавит multi-arch, uint может стать platform-pointer-width unsigned (как Rust’s usize). Bootstrap-grade alias.

Acceptance criteria.

• let x uint = 42 as uint компилируется
• int as uint saturates (neg → 0) — nova_int_to_uint helper
• int as u64 остаётся bit-cast (no saturation)
• []uint → NovaArray_uint64_t*
• Option[uint] → NovaOpt_uint64_t
• 3 fixtures nova_tests/plan70_5/ PASS
• 0 regressions
• uint.MAX — defer (parser keyword support)

Реализовано: Plan 70.5 — Ф.1-Ф.3 closed 2026-05-19.

Связь:

• D54 — as-cast saturation precedent
• D129 — int/i64 alias (signed symmetric pair)
• Plan 07 — original float→int saturation
• Plan 70.5 — parent plan (этот блок)
• Plan 70.4 — sibling (codegen type distinction family)

D133. type X consume — обязательная consume-семантика (must-be-consumed)

Plan 100.1. Принято 2026-05-23 (proposed; implementation pending). Extends D131 affine consume qualifier.

Что

Квалификатор consume на type-decl. Помечает, что инстансы такого типа обязаны быть потреблены до выхода из scope’а на каждом code- path’е. Compile error если live consume-переменная остаётся на exit- point’е.

type Transaction consume { id int }
type File consume { fd i32 }
type Lock consume { mutex *Mutex }

Расширяет D131 с противоположной стороны:

Канонический use-case — Transaction.commit() / .rollback(), File.close(), lock-guard .release().

Синтаксис

consume стоит после имени типа, перед {:

type Transaction consume {                    // type-decl marker
    id int,
}

fn Transaction consume @commit() -> ()         // consume-method (D131)
fn Transaction consume @rollback() -> ()

consume на type-decl + хотя бы один consume-метод (D131) — обязательное сочетание (compile error: «consume-type требует ≥1 consume-method»).

Правило — must-consume на каждом exit-path’е

Compiler проводит flow-sensitive анализ (расширение Plan 73 D131 check_consume pass’а). Для каждой переменной consume-типа отслеживается VarState:

• Live — значение доступно, обязательство активно.
• Consumed — значение потреблено (через consume-метод / consume- параметр / return).
• MaybeConsumed — потреблено лишь на части путей (branch join).

На каждой точке выхода scope’а проход по active consume-переменным:

• Live или MaybeConsumed → compile error E (D133-not-consumed) с указанием консьюм-методов.
• Consumed → OK.

Точки выхода:

• конец function body (последний statement);
• return expr — все live consume-vars (кроме возвращаемой) → error;
• panic / expr!! / expr? / unwinding-paths;
• loop break;
• branch join if/match — Live ⊔ Consumed = MaybeConsumed.

defer / errdefer могут покрывать обязательство (см. D158+ Plan 100.4 family).

Что считается consume

Заразность через поля + explicit double-marker

Record/sum, имеющий поле consume-типа, обязан быть объявлен consume:

type TxState consume {                         // ← ОБЯЗАТЕЛЬНО
    consume tx Transaction,                    // ← ОБЯЗАТЕЛЬНО (тип = consume)
    writes []Write,                            // обычное поле
}

Compiler enforces consistency:

• consume-поле без consume-маркера → error E (D133-field-marker-missing);
• consume-маркер на field без consume на type-decl → error E (D133-type-marker-missing);
• consume f int (тип поля не consume) → error E (D133-marker-on- non-consume) — keyword использован но не нужен.

consume-type БЕЗ consume-полей разрешён — каноничный паттерн для opaque-resource типов (StringBuilder consume с runtime backing через external type; consume-method @into() потребляет; никаких consume-полей в декларации). Достаточно хотя бы одного declared consume-метода.

Field-aware flow внутри методов record’а

@field отслеживается как независимый VarState slot. На exit’е метода:

Это позволяет реальные паттерны (rotate / reopen / replace):

type Service consume {
    consume file File,
}

fn Service mut @reopen() -> Result[(), OpenErr] {
    consume new_file = File.open()?            // сначала добываем замену
    @file.close()                               // только теперь закрываем старое
    @file = new_file                            // rebind — @file опять Live;
                                                //  new_file → Consumed (transfer в @file)
}                                               // mut exit: @file Live ✅

Compiler ловит реальные баги:

• забытый rebind на ветке → exit MaybeConsumed → error.
• early return без rebind → error.
• наивный close-then-open с error-path (@file.close(); @file = open()?) → error если open Err (@file Consumed, не rebinded).

Assign в Live consume-поле / locals — запрещено

Прямое присваивание @field = expr разрешено только когда @field уже Consumed (для simple-typed consume-поля) либо все consume-sub- fields внутри @field уже Consumed (для nested-consume-record-поля). Иначе compile error E (D133-assign-live-field).

fn Service mut @overwrite_naive() {
    @file = File.open()?                       // ❌ @file Live, silent overwrite
}

fn Service mut @overwrite_correct() {
    @file.close()                              // @file → Consumed
    consume new = File.open()?
    @file = new                                // ✅ @file Consumed → assign OK
}

Nested case — @inner содержит consume tx; assign в @inner разрешён когда внутренний @inner.tx уже Consumed (recursively для deep nesting):

fn Outer mut @reset() {
    @inner.tx.commit()                         // @inner.tx → Consumed;
                                               //  @inner effectively «empty container»
    consume new = Inner.new()
    @inner = new                               // ✅ all consume-sub-fields Consumed
                                               //  → @inner replace OK
}

То же для локальных consume-var: повторный consume tx = ... без consume старой — error.

Nested field paths

Multi-level field tracking — ConsumeCtx хранит state по произвольно глубокому пути @f1.f2.f3:

type Inner consume { consume tx Transaction }
type Outer consume { consume inner Inner }

fn Outer mut @commit_inner() {
    @inner.tx.commit()                         // deep path consume; @inner.tx → Consumed
                                               //  @inner — «empty container» (consume-sub-field Consumed)
    consume new = Inner.new()
    @inner = new                               // rebind inner — assign OK
                                               //  (внутренний tx был Consumed)
}

Реализация — ConsumeCtx::states: HashMap<FieldPath, VarState> где FieldPath = Vec<String>.

Заразность через generic-args

type_is_consume(TypeRef) — рекурсивная функция (общая, не Option- специфичная):

• тип в LinearityRegistry (объявлен consume)?
• record/sum с ≥1 consume-полем?
• generic-wrap G[T1, ..., Tn] — хотя бы один Ti consume?
• generic-param T (без bound) — false (bootstrap silent-ignore; закрывается D156 Plan 100.2 через [T consume] bound).

Option[Transaction] / Result[Transaction, E] / Box[Transaction] / user Wrapper[Transaction] — все автоматически consume через wrap. Никакого Option-специфичного хардкода — общее правило для любого generic-wrapper’а.

Три mode’а binding-position: view / mut-view / consume

Единое правило везде (param / for / match / if-let / let-binding): consume keyword маркирует ownership. Без него — view (read- only borrow). mut — view + mutation.

fn read(tx Transaction) -> int                 // view (default; callee читает)
fn modify(mut tx Transaction)                  // mut-view (+ mut методы)
fn close(consume tx Transaction)               // consume (transfer; tx → Consumed)

View (default — без qualifier’а)

Mut-view (mut tx qualifier)

То же что view, но mut-методы разрешены. Не consume, не escape.

Consume (consume tx qualifier)

Полный ownership-transfer. Callee/binding обязан consumed до scope- exit’а через один из 5 механизмов (см. §«Когда consume binding считается удовлетворённым»).

Consume-rvalue в arg-position (без binding)

Прямой call f(make_tx()), где make_tx() -> Tx consume возвращает fresh consume-owner, без сохранения через consume name = … — правила по qualifier’у callee-param:

Почему запрет на view / mut-view: view/mut-view-param не consume’нят callee-стороной. После возврата из f rvalue остаётся не consumed и не bound к локальной переменной → flow-checker не имеет slot’а в ConsumeCtx для tracking’а → must-consume gate его не увидит → ресурс утечёт молча. Запрет — единственное безопасное правило: consume-value требует именованного owner’а либо немедленной передачи ownership через consume-param.

Hint в diagnostic: «привяжи через consume name = make_tx(), затем f(name); после consume-method/consume-param/return name будет Consumed». Альтернатива — заменить sig f на consume-param, если callee действительно должен потребить.

Цепочки (g(f(make_tx()))) — рекурсивно: rvalue-результат f анализируется по тому же правилу для соответствующего param’а g. Если f возвращает consume-value, а g-param это view → error на внешнем вызове.

Глубокий peek без consume

match @file {                                  // view-match (default)
    Some(f) => f.fd,                           // f: view File, read-only
    None => 0,
}
// @file остаётся Live ✅

См. D157 (Plan 100.3) — match-pattern в view-mode + closure capture analysis.

consume + -> @ несовместимы

fn Tx consume @prepare() -> @ { ... } → parse error. Противоречие между «забираю целиком» и «возвращаю тот же объект» (D132 fluent- return).

Binding: consume keyword обязателен для ownership

Для consume-типов consume keyword обязателен в LHS, когда binding становится Live-linear-owner:

ro tx = begin()                               // ❌ ERROR D133-consume-needs-keyword:
                                               //    consume-type требует `consume` keyword

consume tx = begin()                           // ✅ initial binding — owns

ro alias = tx                                 // ✅ view-alias (no ownership; Plan 73)
mut alias = tx                             // ✅ mut-view-alias
consume new_owner = tx                         // ✅ transfer: tx → Consumed

Без consume keyword’а LHS = view-alias (alias-class Plan 73, read-only borrow). Это симметрично param/for/match — везде «no qualifier = view, consume = transfer».

Когда consume binding считается удовлетворённым

Live consume-binding обязан к scope-exit’у оказаться в одном из 5 состояний:

1. Closed locally — tx.commit() (consume-метод).
2. Returned — return tx.
3. Transferred — f(tx) где f(consume tx T).
4. Stored in record-field, который сам уходит наверх:

   consume tx = begin()
   return Wrapper { tx: tx }                  // tx → record-field, record returns
   

5. Covered by defer/errdefer/okdefer (D158-D162 Plan 100.4 family).

Иначе error E (D133-not-consumed).

AI-first explicit-ness — почему mandatory

consume keyword обязателен специально — для loud visibility:

• 🟢 Каждое появление ownership видно с первого взгляда.
• 🟢 Refactor-safety — добавил consume к типу → compiler ловит все существующие let x = T.new() sites, force review.
• 🟢 Единое правило симметрии с param / for / match.

Verbose-ness bounded — только для consume-типов (rare; resource- management).

Runtime mental model (Option-projection, не ABI)

Концептуально consume-тип проецируется в Option[T]-space:

• Live ≡ Some(t).
• Consumed ≡ None.
• MaybeConsumed ≡ branch-зависимо.

Это mental model для spec/docs. Реализация остаётся pragmatic (D131-style):

• pointer-based consume: NULL = None (zero overhead);
• value consume: zero-out fields после consume;
• compile-time check_consume — основной механизм; runtime null-deref panic — defense-in-depth.

User-facing pattern-match match tx { Some(t) => ... } для runtime- проверки не вводится — ослабит compile-time гарантии.

Что отвергнуто

• Universal affine/linear для всех let — отвергнуто в D75 §«Compile-time token-scope enforcement»: «это Rust borrow checker ради одной фичи, несоразмерно для GC-языка». D133 — opt-in per-type, не default.
• Suppress-механизм let _ = v — anti-Rust #[must_use] gateway. Единственный канал — consume-метод. Если «иногда хочу забыть» — знак, что тип неправильно помечен consume.
• Drop-method auto-cleanup (Rust-style RAII) — размывает выбор commit/rollback. D133 требует явный consume-метод.
• Pattern-match destructure consume-record (let { tx } = state) — ломает encapsulation (consume-поле уходит в независимый linear- binding). Вынос через явный consume-метод record’а: fn TxState consume @into_parts() -> (Transaction, []Write) => (@tx, @writes).
• Strict-mode binding-form (let tx = «обязан передать наверх» vs consume tx = «обязан закрыть здесь») — отвергнуто (overspec, refactor friction). Финальная модель: consume keyword mandatory для ownership; let для consume-types = error либо view-alias (в alias-position).
• view T keyword как explicit qualifier — отвергнуто (default- view достаточно). view mode = absence of consume/mut qualifier (см. D157 Plan 100.3).
• Implicit _ = tx discard — суррогат suppress; force compile- error.

Сравнение с другими языками

D133 строже Rust на suppress (нет mem::forget), expressive Rust на distinct cleanup methods. Не требует lifetime’ов / move-семантики.

Связь

• D131 — affine consume foundation. D133 — extension on type-decl level.
• D132 — -> @ fluent-return; sound builder-chain alias через -> @ нужен для consume-checker’а builder API.
• D75 — почему universal consume отвергнут.
• D90 — defer / errdefer foundation; интеграция через Plan 100.4 family (D158-D162).
• D85 — kinded throws, cancel-routing; взаимодействие через D162 Plan 100.4.5.
• D156 Plan 100.2 — generic [T consume] strict-mode bound.
• D157 Plan 100.3 — view T read-only borrow для deep peek.
• D158-D162 Plan 100.4.1-5 — defer/errdefer integration для cleanup- on-failure.
• D163 Plan 100.5 — FFI external consume fn.
• D164 Plan 100.6 — cross-module consume visibility + mangling.
• D165 Plan 100.7 — stdlib migration playbook.
• D166 Plan 100.8 — performance + IDE tooling.

D156. Generic [T consume] bound + collection-aware iteration

Plan 100.2. Принято 2026-05-23 (proposed; implementation pending). Extends D133 на generic-код. Closes silent-leak hole для consume-T в generic-функциях.

Что

Bound [T consume] на generic-параметр — opt-in strict mode: внутри generic-body параметр T трактуется как possibly-consume; silent-forget T-значения → compile error. Backward-compat: generic-функции без bound сохраняют silent-ignore behavior (Plan 100.1 default), чтобы existing stdlib generic-код продолжал работать.

// Strict mode — compiler enforces strict consume handling внутри:
fn box[T consume](consume x T) -> Box[T] => Box { val: x }

// Без bound — silent-ignore:
fn drop[T](x T) -> ()                          // silent forget если T consume

Плюс — collection-aware iteration с 3 mode’ами (unified с D133): for tx in vec (view default) / for mut tx in vec (mut-view) / for consume tx in vec (consume, vec → Consumed).

Зачем

Без D156 generic-код имеет дыру:

type Transaction consume { id int }
fn Transaction consume @commit() -> ()

fn first[T](pair (T, T)) -> T => pair.0       // silent leak pair.1 если T=consume

consume tx1 = Transaction { id: 1 }
consume tx2 = Transaction { id: 2 }
consume chosen = first((tx1, tx2))             // tx2 уехала в first и потерялась
chosen.commit()
// tx2 LEAK — compiler молчит.

Это самый серьёзный hole D133 bootstrap’а — именно generic-helpers есть в каждой stdlib. Rust решает через Move trait + ownership; D156 решает через [T consume] bound + collection-aware iteration.

Синтаксис bound

fn box[T consume](consume x T) -> Box[T]
fn map[T consume, U consume](items []T, f fn(consume T) -> U) -> []U
fn id[T consume](consume x T) -> T => x

consume — bound в generic-position, мирится с другими bounds ([T Iter[U]] из D72) — но bootstrap не поддерживает комбинации ([T consume + Clone] — parse error; будущее расширение).

Strict mode внутри [T consume] body

Внутри функции с [T consume] bound параметр T трактуется как possibly-consume; compiler обращается строго:

Force’ит honest API. Чтобы legitimately drop элемент — нужен явный consume-параметр для drop:

fn first[T consume](consume a T, consume drop_b T) -> T => a
//                              ^^^^^^^^^^^^^^^^^^ — caller обязан передать
//                                                   drop_b как consume; внутри
//                                                   first drop_b силен забыть
//                                                   (это локальный binding).

Backward-compat и migration policy

• Default = silent-ignore для generic-functions без bound (Plan 100.1 behavior preserved). Иначе сломается весь stdlib generic-код.
• Opt-in [T consume] для функций, которые хотят strict mode.
• Migration: stdlib generic-functions (Plan 17/26/30/52/57 collection API) — постепенно аннотируются [T consume] через nova consume-migrate CLI (Plan 100.7).

Collection-aware iteration — 3 mode’а

Симметрично D133 param/match mode’ам:

consume tx1 = begin()
consume tx2 = begin()
consume txs = [tx1, tx2]                       // []Transaction — generic-заразность (D133 D6)
                                               // txs владеет (consume keyword обязателен)

// View (default) — read-only, vec stays Live:
for tx in txs {
    println(tx.id)                             // ✅ read field
    // tx.commit()                             // ❌ view → не consume-метод
}
// txs Live после for; нужно consume другим способом.

// Mut-view — vec stays Live, элементы mutated in-place:
for mut tx in txs {
    tx.update()                                // ✅ mut method
}
// txs Live, элементы updated.

// Consume — consume каждое, vec → Consumed:
for consume tx in txs {
    tx.commit()                                // ✅ consume-метод
}
// txs → Consumed после for ✅

Loop-handling pragmatic: for consume tx in vec помечает vec Consumed после loop (даже если break early — D161 multi-defer LIFO error accumulation gracefully handles partial-consumed state).

Каждый tx в arm-теле проверяется стандартным check_consume правилом для соответствующего mode’а (view / mut-view / consume).

Alternative consume-methods для collection

Чтобы consume collection без iteration:

• vec.pop() -> Option[T] — single-element consume (Option auto- consume через D133 D6 generic-заразность).
• vec.drain() -> Iter[T] — consume через iterator.
• vec.into_first() -> T consume-method record’а возвращает один элемент (consume rest internally).

stdlib audit (Plan 100.7) аннотирует эти методы с [T consume] bound.

Generic propagation для HOF (map/filter/fold)

Closure-параметры HOF используют те же 3 mode’а через qualifier:

fn map[T consume, U consume](consume items []T, f fn(consume T) -> U) -> []U
fn filter[T consume](consume items []T, f fn(t T) -> bool) -> []T
//                                          ^^^ — view (default; read-only)
fn for_each[T consume](consume items []T, f fn(consume T) -> ())
fn modify[T consume](mut items []T, f fn(mut T) -> ())
//                                       ^^^^ — mut-view (in-place modify)

filter использует view-closure (default) — predicate читает T без consume. map consume’ит каждое T → producer’ит U. modify mut-view для in-place.

Compiler enforces consume-handling в closure-body через generic-bound propagation + view-default rules.

HashMap / user-generic propagation

type_is_consume рекурсивно (D133 D6): wrapper’ы с consume-arg сами становятся consume:

consume tx_map = HashMap[str, Transaction].new()
                                               // ↑ Transaction consume → HashMap consume
                                               //   через generic-заразность
                                               //   consume keyword обязателен (D133)
tx_map.insert("a", consume begin())            // insert требует consume value (transfer)
// На scope-exit tx_map должен быть Consumed (через consume-метод HashMap).
for consume (_, tx) in tx_map.drain() {        // consume через drain-iteration
    tx.commit()
}

HashMap (и другие collection API) — должны аннотировать [V consume] на методах, манипулирующих consume-values (insert(k K, consume v V), remove() -> Option[V], drain() -> Iter[(K, V)], etc.). Migration audit — часть Plan 100.7.

Runtime cost

Zero. Все проверки compile-time. Runtime-представление generic’ов не меняется. Bound [T consume] — type-level only, не влияет на codegen mono’d functions.

Сравнение

Nova превосходит Rust на одной оси — backward-compat: generic без bound сохраняет existing behavior; opt-in strict — choice.

Что отвергнуто

• [T consume + Clone] combined bound — bootstrap parse-error; будущее расширение (комбинация с другими D72 bounds).
• [T !consume] anti-bound — не вводится; нет use-case в bootstrap.
• Variance linear-typed wrappers — отдельный план (общая variance system).

Связь

• D133 — foundation type-level consume; D156 — generic-уровень.
• D72 — generic bounds [T Protocol]; D156 идиоматически близок.
• D157 — view T (Plan 100.3); filter-style HOF использует view для read-only inspection.
• D158-D162 (Plan 100.4 family) — defer/errdefer integration; orthogonal.

D163. FFI consume integration — type-driven, без отдельного keyword’а

🔴 RETRACTED 2026-05-30 (Plan 91.10). needs <Cap> syntax удалён. Capability tracking via отдельный mechanism — redundant с effect system (Plan 33). Structurally needs Cap ≡ effect-без-операций: same propagation, same static tracking, different syntax. Если в будущем понадобится capability gating — вводить как formal effect declarations (type Fs effect { ... }) с handler’ами. Конкретный pain: consume (ownership/linearity) vs capability (authority) — orthogonal concerns, D163 их жёстко связал. См. [docs/plans/91.10-d163-retract-capability-syntax.md].

Что осталось от D163:

• external type X consume в любом module — продолжает работать (D126 + опаковая FFI-семантика).
• consume keyword на параметрах external fn — продолжает работать (D131 ownership). Но external fn остаётся stdlib-only (D82) — user-module external fn через D163 capability path больше не валидны.

Plan 100.5 historical original record: Принято 2026-05-23. Ред. 2 (2026-05-24): drop external consume fn keyword. Ред. 3 (2026-05-27): РЕАЛИЗОВАНО — parser needs clause, type-checker D163-missing-cap, C codegen стабы. Extends D82 external fn + D126 external type + D63 capability.

Удалено (Plan 91.10):

• Parser needs clause (hard error w/ migration hint).
• check_external_fn_needs_caps (D163-missing-cap diagnostic).
• emit_d163_external_stub (C codegen стаб generator).
• FnDecl.needs_caps AST field — удалён (Plan 91.15 Ф.5, [M-91.10-remove-needs-caps-field] ✅).
• Test fixtures nova_tests/plan100_5/external_* (6 files) и nova_tests/plan100_7/{file_open_read_close,mutex_lock_release, socket_listen_accept}.nv (3 files).

Текст ниже — historical reference для контекста.

Что

Никакого нового keyword’а для external fn — унифицировано с regular fn: return-type carrying consume-ness (через D133 type-decl consume) автоматически передаёт ownership caller’у. consume keyword используется только на параметрах/receiver’ах (D131 semantic).

// Opaque consume-type (D126 + D133):
external type File consume
external type Mutex consume
external type Socket consume

// Return consume-type → caller получает ownership (через type, не keyword):
external fn nova_file_open(path str) -> File
    needs Fs                                    // capability required (D63)

// Param-side consume — D131 semantic, тот же keyword `consume` на param:
external fn nova_file_close(consume f File)
    needs Fs

// Result wraps consume — generic-заразность из D133 D6:
external fn nova_open(path str) -> Result[File, IoErr]
    needs Fs
// Caller обязан consume Result через match-Ok-arm.

Зачем drop keyword

Параллель с regular fn:

fn factory() -> Transaction => Transaction.new()
//              ^^^^^^^^^^^ — return type carries consume-ness. NO `consume`
//                            keyword on fn declaration.

fn finish(consume tx Transaction) -> () { ... }
//        ^^^^^^^ — consume on PARAM (D131).

Применяем то же к external — symmetry без нового keyword’а.

Capability requirement (D63)

external fn касающийся OS resource обязан declare capability — это независимо от consume-семантики (общее правило D63):

external fn nova_file_open(path str) -> File
    needs Fs                                    // OS access → cap required

external fn nova_socket_accept(consume srv ServerSocket) -> ClientSocket
    needs Net

Capability и consume — две ortogонные concern. Capability для OS privilege; consume для ownership. Combined через type-decl + needs-clause.

C runtime defensive helpers

C-side nova_file_close(consume f File) обязан:

• nv_consume_validate(f) — assert f != NULL на entry.
• После работы — memset поля File* в zero / NULL (defense-in-depth per D131 Plan 73 pattern).

Это даёт двойную защиту: compile-time (D133 check_consume) + runtime (NULL-deref panic на use-after-consume).

Generic-заразность через FFI — uniform

external fn nova_open() -> Result[File, IoErr] needs Fs
//                         ^^^^^^^^^^^^^^^^^^^ — Result consume через generic-arg
// Caller обязан consume Result (через match Ok-arm с consume File).

Никакого FFI-специфичного правила — общее D133 D6 generic-заразность.

Cross-fiber FFI safety

FFI-call может суспендиться (libuv async I/O). Plan 47/22/49 fiber infra preserves consume-state через migration; D163 verify через runtime tests (Plan 100.5 Ф.6).

Сравнение

Nova превосходит Rust — (a) нет unsafe keyword (D6 + D63 capability); (b) уни­фи­цировано с regular fn (одна mental model для FFI и Nova-side functions).

Что отвергнуто

• external consume fn keyword (Ред. 1) — избыточный, return-type уже carries consume-ness. Drop в Ред. 2.
• Vacuous-marker warning (Ред. 1 W D163-vacuous-consume) — отпадает вместе с keyword.

Связь

• D82 — external fn foundation; D163 расширяет.
• D126 — external type opaque; combine’ится с consume.
• D63, D64 — capability enforcement.
• D131, D133 — consume foundation.
• Plan 18 — основной consumer (File/Mutex/Socket migration).

D164. Cross-module consume — visibility + mangling + package contracts

Plan 100.6. Принято 2026-05-23 (proposed). Extends D26 visibility + D134 mangling v0 + Plan 03 package ecosystem.

Что

consume-маркер (D133) — part of exported type signature. Visibility (D26, D47 Plan 35 R26) propagates marker. Symbol mangling (extends D134 Plan 81) включает consume-bit — ловит cross-version ABI break. Plan 03 nova audit verifies cross-package consume-contracts.

Cross-package visibility

// package A, module a/types.nv
export type Transaction consume {
    id int,
}

// package B, module b/main.nv
import a.types.Transaction

fn main() {
    consume tx = Transaction { id: 1 }          // ✅ consume-marker visible
    tx.commit()
}

consume propagates через export + import. Plan 35 R26 (visibility enforcement) — без special-case’ов; consume — обычный type-attribute.

Mangling extension (D134 amend)

Plan 81 D134 определил symbol-mangling v0:

nova_fn_<pkg>_<mod>_<name>_<param-types>_<return-type>

D164 amend:

nova_fn_<pkg>_<mod>_<name>_<consume-bit>_<param-types>_<return-type>
                          ^^^^^^^^^^^^^^^
                          `c` если consume-маркер на type-decl, `_` иначе

Это ловит ABI mismatch — package A v1.0 имеет Transaction consume, v2.0 убрал marker; linker ловит cross-version mismatch на load.

Re-export через export import (Plan 42.09)

// package B re-exports A.Transaction
export import a.types.{Transaction}

Re-export preserves consume-marker. Plan 42.09 уже работает; D164 verifies.

Folder-modules (Plan 42) + relative imports (Plan 84)

consume-types работают идентично в folder-modules + relative imports: не вводятся special-case rules. Plan 42 / Plan 84 уже работают; D164 verifies.

Package version contracts (Plan 03)

nova.toml consume-contracts:

[package]
name = "my_lib"
version = "1.0.0"

[exports.consume_types]
Transaction = "1.0"                             // consume contract v1
File = "1.0"

Cross-version compat:

• v1.0 → v1.x — consume-status unchanged.
• v1.x → v2.0 — consume-status может change (major-bump required).

nova audit (Plan 03.4) verifies — ловит «v1 → v1.1 breaking change» unauthorized.

Cross-module diagnostic

error: consume value `tx` (type a::Transaction) not consumed
  note: type defined in package 'a' v1.0 at a/types.nv:5
  note: consume via .commit() or .rollback() (declared in 'a')

Includes package origin, version, consume-method hint.

Private consume не leak

type InternalCache consume { ... }              // no `export`
// usable только в этом package; cross-package — invisible

Plan 35 R26 — без special-case’ов.

Сравнение

Nova matches Rust на всех осях; превосходит на consume-bit-in- mangling (ловит silent ABI mismatch которого Rust не видит через type-id alone).

Связь

• D26, D47, Plan 35 R26 — visibility foundation.
• D134 — mangling v0 (Plan 81); D164 extends.
• D29 — modules + folder-modules.
• D126 — opaque types; cross-package consume может быть opaque.
• D131, D133 — consume foundation.
• Plan 03 / Plan 03.4 — package ecosystem, nova audit.
• Plan 42, Plan 42.09, Plan 84 — folder-modules, re-export, relative imports.

D135. Type-checker completeness — «no silent fallback» на уровне типов

Статус: принято, реализовано (Plan 79).

Контекст. D368 закрыл silent-fallback в кодогене («no silent nova_int»). Но bootstrap type-checker (types/mod.rs) проверял имена, структуру, эффекты, контракты — и не базовую совместимость типов. Эмпирическая перепроверка 2026-05-21 показала: ряд элементарных ошибок типов компилировался молча (silent miscompilation) либо ловился только C-компилятором (CC-FAIL, поздняя нечитаемая диагностика):

Go / Rust / TS ловят все пять на compile-time. По базовой проверке типов Nova была позади всех трёх.

Решение. Type-checker обязан ловить базовые ошибки типов на этапе компиляции собственной диагностикой (серия E73xx), а не молча и не перекладывая на C-компилятор. Отдельный проход TypeCheckCtx (паттерн NameResCtx / MapLitCtx):

• E7310 — арность type-аргументов. Использование generic-типа с явно указанным, но неверным числом аргументов (Result[int], Result[A,B,C], Foo[int] для не-generic Foo). Опущенные аргументы (fn f() -> Result { Ok(1) }) — легальны (выводятся из контекста), это не arity-ошибка.
• E7301 — assignability. let-аннотация ↔ RHS и аргумент ↔ параметр. Целочисленный литерал полиморфен (D44): let x u8 = 200 валиден; let x int = true, want_bool(42) — нет. Сравнение по категориям типов; structural-конформность протоколов — забота D72, не этой проверки.
• E7320 — существование поля / метода. obj.name, где obj — concrete record: name обязан быть полем либо методом (into/ try_into синтезируются из D73/D77).
• E7330 — type-vs-value. Имя непустого record/sum-типа в value-позиции (let c = Foo, Foo + 1) — ошибка: тип не значение.

Принцип «no any-hole» (строже TS). Ни один путь проверки не присваивает выражению результат «молча неверно». Там, где тип выражения не выводится (bootstrap type-checker по дизайну не типизирует каждое выражение — вывод завершается в кодогене), проверка пропускается локально — это не silent miscompilation: программа не становится неверной, недостающая проверка либо ловится дальше по пайплайну, либо случай корректен. any — только из явной аннотации ([]any), он не «заражает» и не отключает проверку соседних выражений. Полная типизация каждого выражения на уровне type-checker’а — задача пост-bootstrap full inference engine, вне scope Plan 79.

Сравнение. Go/Rust/TS ловят все пять случаев на compile-time; Plan 79 выводит Nova на их уровень для перечисленных проверок. Строже TS: у TS any молча гасит ошибки — в Nova такого пути нет.

Связь:

• D368 — sibling: «no silent fallback» для кодогена (Plan 70).
• D44 — полиморфизм числовых литералов.
• D72 — structural bounds (конформность протоколов — там).
• D73 / D77 — into/try_into синтез.
• Plan 79 — родительский план (этот блок).
• Plan 37 — newtype/alias as-cast строгость (смежная, отдельная).

D142. protocol/effect declaration ↔ literal symmetry

Plan 97. Принято 2026-05-23. Объединяет Q-keyword-symmetry (open-questions.md) с Q-static-method-protocol (D58).

Что

Декларация и литерал и для протоколов, и для эффектов — симметричны по ключевым словам:

// Declaration:
type Cron effect   { run() -> () }
type Fan  protocol { run() -> () }

// Literal (значение, реализующее контракт):
ro h = effect   Cron { run() => spawn_cron() }   // value of type Effect[Cron]
ro p = protocol Fan  { run() => spin_blades() }  // value реализующее Fan

Раньше литерал эффекта писался ключевым словом handler, а литерала протокола не было. Теперь:

• литерал эффекта — effect X { ... } (тот же keyword, что в declaration);
• литерал протокола — protocol X { ... } (тот же keyword, что в declaration);
• встроенный тип Handler[E, IRT] → Effect[E, IRT] (Effect[E] ≡ Effect[E, Never] через D88 default).

Clean break — старое ключевое слово handler (литерал) удалено без deprecated-алиаса; парсер при встрече выдаёт diagnostic «handler keyword removed; use effect (D142)».

Правило

Декларация (без изменений)

type Db   effect   { query(q str) -> [str] }
type Hash protocol { hash() -> u64 }

Литерал — symmetry

// effect-литерал (value)
ro h = effect Db {
    query(q) => mock_rows()
}
with Db = h { ... }

// protocol-литерал (value реализующий контракт) — instance-only
ro l = protocol Locker { lock() => state.lock() }

Анонимный protocol в type-position (D53 §628)

fn close_all(items []protocol { close() -> () }) {
    for it in items { it.close() }
}

fn min[T protocol { @lt(other Self) -> bool }](xs []T) -> Option[T] => ...

Body анонимного protocol — тот же синтаксис, что у named: bare-имена = instance; leading-точка .method = static (D143).

protocol-литерал: instance-only

Static-методы — это методы типа (Type.method, D35); у литерала нет «своего типа» (анонимная impl). Попытка реализовать static в protocol-литерале → diagnostic «static methods cannot be implemented in protocol-literal; they belong to a type (D35) — use a named type».

Capture-rules

Закрытие над окружающим scope’ом — как обычное closure (D22 / D6 managed heap). Никаких особых правил поверх closure не вводится.

Почему

• Симметрия снижает когнитивный налог. Один keyword из declaration работает и в literal — нет «двух жаргонов» (handler vs protocol vs effect).
• Анонимный protocol-литерал разблокирует pattern «capability-split factory» — Lock.new() -> (Locker, Unlocker) без двух named-обёрток. Кандидаты в stdlib Plan 18: Process.spawn, HttpServer.bind, Db.transaction.
• Symmetry побеждает локальную точность. let h = effect X { ... } читается чуть точнее как «handler», но protocol X { ... }-литерал всё равно нужен — приходится либо ввести ещё keyword, либо унифицировать. Унификация чище.
• Clean break без deprecated — текущая база .nv маленькая (~30 файлов); миграция атомарным sweep’ом дешевле двух-keyword’ового периода + последующей чистки.

Что отвергнуто

• Protocol[P] first-class тип — отвергнут как избыточный. Для эффектов Effect[E, IRT] нужен, потому что значение эффекта передаётся в with X = h (нужна типизация значения). У протоколов «значение, реализующее контракт» — это тип реализации; обёртка не нужна. Тривиальный alias решит, если когда-нибудь понадобится (Q-protocol-type-wrapping).
• deprecated handler alias — отвергнут (clean break, ~30 файлов миграции).
• Static в protocol-литерале — отвергнут (нет «своего типа»; см. D35).
• Изменение семантики handler’ов — нет, только rename keyword’ов.

Связь

• D53 — protocol declaration; D53 §628 (анон-protocol в type-position) ✅ реализовано (Plan 97 Ф.2).
• Protocol-литерал codegen — value protocol Name { ops } с runtime vtable + dispatch — ✅ реализовано в подплане Plan 97.1 (emit_protocol_lit + расширенный Plan 56 D122 box-pattern). Capability-split factory pattern работает end-to-end.
• D61 — handler-литерал; rename keyword handler → effect (Plan 97 Ф.3).
• D87 — Effect[E, IRT]; rename в Effect[E, IRT] (Plan 97 Ф.3).
• D88 — default generics (Effect[E] ≡ Effect[E, Never]).
• D143 — .method-префикс для static в protocol-body (закрывает Q-static-method-protocol).
• D35 — static vs instance методы.
• D22 — closure capture-rules.
• Q-keyword-symmetry — закрывается этим D-блоком.
• Plan 97 — имплементация parser + AST + type-checker.
• Plan 97.1 — runtime codegen (vtable + dispatch) + followup-hardening (Nova-side enforcement, capture-mode by-value snapshot для factory, shadowing fix, scan_fwd recurse, GC stress, multi-method, nested).
• Ориентиры: Java/Kotlin (anonymous interface), TS (object-literal structurally), Koka/Eff (handler-literal).

Canonical example — capability-split factory pattern

Use-case D142, разблокированный Plan 97.1 codegen’ом:

type Reader protocol { read() -> int }
type Writer protocol { write(v int) -> () }

type Cell { mut value int }

fn Cell.new(initial int) -> (Reader, Writer) {
    ro state = Cell { value: initial }
    ro r = protocol Reader { read() => state.value }
    ro w = protocol Writer { write(v) { state.value = v } }
    (r, w)
}

// caller:
ro (r, w) = Cell.new(10)
ro initial = r.read()    // 10
w.write(99)
ro after = r.read()      // 99 — shared state через protocol-литералы

Реализация (Plan 97.1 emit_protocol_lit, Approach A):

1. Литерал protocol Reader { read() => state.value } создаёт synthetic struct Nova_ProtoLit_<N> с capture-field state.
2. Free fn Nova_ProtoLit_<N>_method_read(self, ...) использует self->state->value.
3. Allocate NovaVtable_Reader* + ctx; patch vt->read = impl_fn.
4. Возврат NovaBox_Reader { .data = ctx, .vtable = vt } (fat-pointer pattern Plan 56 D122).

Method dispatch r.read() → r.vtable->read(r.data) — стандартный vtable indirect call.

Capture-rules:

• Heap obj / let mut → by-pointer (alias, mutation visible).
• Immutable scalar / fn-param → by-value snapshot (factory-safe, survives fn exit).

D144. Sub-slice views для []T и str — arr[a..b] / s[a..b]

Amended (Plan 138 D238+D239, 2026-06-10): arr[i] для user-типов (Vec[T], HashMap[K,V] и т.д.) теперь через @index protocol (D238). []T = Vec[T] (D239); typed-storage gap закрыт — []Option[int], []Record и другие exotic-element типы получают правильное typed хранение. Range-slicing v[2..5] для Vec[T] — через @index(Range) overload. Предложение «future language version» из D232 Migration path снято: D239 фиксирует []T ≡ Vec[T] как текущую спецификацию.

Источник: Plan 96 (2026-05-23). Закрывает Q-array-slicing, Q-array-api.5, D27 §1663 drift («Слайсинг отложен»), D27 §1632 drift (raw arr[i] без bounds-check). Зависит от D6 non-moving GC; D58 Range; D27 []T API; Plan 90 / D141 bulk-ops.

Семантика — sub-slice view

arr[range] где range : Range возвращает view — новый 24-байтовый header NovaArray_T* с data = orig->data + from, len = cap = to - from. Без копии данных backing’а (O(1) creation).

str[range] возвращает codepoint-indexed view (двухпроходный walk UTF-8 → byte offsets; structurally идентично nova_str_slice, но с panic при OOB вместо clamp).

5 форм Range (Rust RangeBounds parity)

Open-ended формы — только в slice-context (arr[range]). В materialize / for-loop / quantifier / parallel-for они отвергаются с compile-time diagnostic «open-ended Range without bound (Plan 96)».

Single-type design

[]T — один тип для owner и view. Нет Slice[T] (Rust-модель раздельных типов). View передаётся в функцию ждущую []T без дополнительной конверсии.

cap == len invariant

View имеет cap == len == to - from. Push на view → realloc (как обычно при exhausted cap) → view silent detach от parent. Parent backing никогда не молча перезаписывается — это устраняет Go-append-footgun без borrow checker’а.

mut parent = [1, 2, 3, 4, 5]
mut view = parent[1..4]   \ view: [2, 3, 4]
view.push(99)                  \ realloc; view detached
\ parent == [1, 2, 3, 4, 5]   — НЕ затронут
\ view == [2, 3, 4, 99]

Mut-семантика

mut-view только от mut-источника. Через mut-view write идёт в shared backing — изменения видны parent. Несколько mut-view одного backing’а разрешены (как в Go); caller responsibility, никакого borrow checker’а.

Iterator invalidation

for x in view — len берётся snapshot’ом в начале цикла (Go-style). Push на parent во время итерации view’а не виден view’у: parent реаллоцирует, view продолжает указывать на старый backing через interior-pointer.

GC requirement — interior pointers stable

Необходимое условие: runtime гарантирует stable interior pointers (non-moving GC, D6). View хранит data = backing->data + from — это указатель внутрь backing’а; Boehm (GC_set_all_interior_pointers(1)) держит backing alive по interior-ptr.

Любая будущая замена GC-backend на moving GC требует одновременной замены slice-представления (separate header struct + ptr-update on move). Это закрепляется здесь как нормативный invariant.

Bounds-check

• from < 0 → panic
• to < from → panic
• to > len → panic (для str — to > total_codepoints)
• Empty slice (arr[a..a]) → валиден
• Отрицательные индексы → panic, не Python-style wrap

Сообщение panic’а: "array: slice [N..M] out of bounds for length L" (паритет с Go/Rust).

Также: raw arr[i] bounds-check (D27 §1632 drift)

D144 одновременно фиксирует pre-existing drift: codegen arr[i] теперь эмитит runtime bounds-check (раньше эмитил голый (arr)->data[i] — controlled buffer overflow на запись, UB на чтение). Сообщение: "array: index N out of bounds for length L".

Concurrency / M:N

Slice-view = shared mut backing между fiber’ами в M:N runtime = формально UB по D79. В D71 single-threaded bootstrap — OK по факту. Передача view через Channel[]T] или spawn-capture в M:N — inherits D79 disclaimer.

Header layout

24 байта (ptr + len + cap) — тот же что у owner. Не оптимизировано до 16 байт (которое требовало бы отдельного типа Slice[T] — отвергнуто single-type-design’ом).

str[a..b] — bracket syntax для строк

Bracket-форма унифицирует idiom: arr[a..b] ≡ str[a..b]. Codepoint-indexed (как существующий nova_str_slice метод). Panic при OOB (consistent с arr[a..b]).

Старый s.slice(a, b) метод — сохраняется с clamp-семантикой для backwards-compat; align на panic откладывается в Plan 94 (см. [P-str-slice-clamp-vs-panic] в docs/simplifications.md).

Verified против

• Go s[a:b] — паритет, без append-footgun.
• Rust &[T] — близко, без borrow checker (caller responsibility для multi-mut).
• TypeScript TypedArray.subarray — паритет.
• Swift ArraySlice<T> — без CoW-disconnect (view сразу видит mut).
• Python memoryview — паритет.

Связь

• D6 — non-moving GC; interior-ptr invariant амендится здесь.
• D27 — []T API; §1632 bounds-check (D144 чинит drift); §1663 «Слайсинг отложен» (D144 закрывает).
• D58 — Range-литералы; D144 расширяет до 5 форм (open-ended).
• D79 — shared mut между fiber’ами = UB в M:N; slice inherits.
• D141 — Plan 90 bulk-ops; работают на view автоматически.

D145. fn[T] префикс — receiver-generic decl + bounds (Plan 101)

Status: MOSTLY CLOSED (2026-05-25, ред. 6 — Plan 101.1/2/3/4 ✅, 101.5 partial). Plan 101.1 codegen для non-int mono-dispatch — marker [M-fn-prefix-int-only-mono] ✅ RESOLVED (Plan 101 Group I, vec_map_int_str fix).

AMEND (2026-06-14, Plan 153.5): вложенные generic-ресиверы произвольной глубины (fn[T] [][]T @m / fn[T] Vec[Vec[T]] @m — structural typevar-bind в самый внутренний элемент, depth-agnostic) — см. секцию «AMEND … вложенные generic-ресиверы» ниже. Разблокировало @flatten (D263); закрыло [M-153.5-flatten-nested-receiver].

Реализовано (Plan 101.1–101.4 + 101.2):

• 101.1 ✅ — Parser fn[T] ReceiverType @method + 5 disambiguation error codes (E_UNDECLARED_TYPEVAR_IN_RECEIVER, E_BARE_TYPEVAR_NEEDS_PREFIX, E_DUPLICATE_GENERIC_DECL, E_PREFIX_SHADOWS_NAMED_TYPE, E_UNUSED_PREFIX_TYPEVAR). Codegen mono []int element + bare-T + non-int element (через Plan 95 array-ext infrastructure). vec.nv migration: 7 методов.
• 101.2 ✅ — Bound integration: method-call bound enforcement (check_method_call_bounds в types/mod.rs); receiver-generic fn[T Bound] []T @m ловит violation на call-site xs.m().
• 101.3 ✅ — Multi-bound [T A + B]: GenericParam.bound → bounds Vec, parser + Type chain, type-check iterate all bounds (conjunction), strict check_generic_bound_declarations (E_BOUND_UNKNOWN / E_BOUND_NOT_PROTOCOL).
• 101.4 ✅ — Protocol composition use TypeName в protocol body: AST TypeDeclKind::Protocol { methods, embeds }, parser parse_protocol_body, type-check flatten DFS + 5 диагностик (E_PROTOCOL_EMBED_{UNKNOWN, NOT_PROTOCOL, CYCLE, DUPLICATE, AFTER_METHOD, NOT_NAMED}).
• 101.5 partial — stdlib audit: только vec.nv использует fn[T] prefix (7 методов работают; non-int — deferred). HashMap/PQ/Lru используют carrier-brackets (Plan 15 D72 path, unchanged).

Deferred (followup):

• vec_map_int_str — T=int U=str cross-type case ✅ RESOLVED (Plan 101 Group I, M-fn-prefix-int-only-mono).
• LSP quick-fixes (Plan 101.5 V2).

Ред. 3 (2026-05-24): complete rewrite после critical review. Ред. 1 описывала narrow fn[T] only. Ред. 2 ошибочно ввела implicit-T (моя misinterpretation D35). Ред. 3 — finalized design: никакого implicit T, fn[T] префикс обязателен везде где receiver не имеет carrier-brackets, + bounds через existing D72,

• multi-bound +, + protocol composition use Foo.

Ред. 5 (2026-05-25): Plan 101.3 (multi-bound [T A + B]) и Plan 101.4 (protocol composition use TypeName — pivot от earlier discussion A1 use A, B к более читаемому line-per-use) финализированы и реализованы.

Ред. 3 (2026-05-24): complete rewrite после critical review. Ред. 1 описывала narrow fn[T] only. Ред. 2 ошибочно ввела implicit-T (моя misinterpretation D35). Ред. 3 — finalized design: никакого implicit T, fn[T] префикс обязателен везде где receiver не имеет carrier-brackets, + bounds через existing D72,

• multi-bound +, + protocol composition use Foo.

Что

Generic-параметры функции в receiver-position декларируются по одному из двух механизмов, в зависимости от формы receiver’а:

1. Carrier-brackets на named generic-типе — existing D119:
   • fn Option[T] @map[U] — T в Option[T] декларирует T.
   • fn HashMap[K, V] @keys() — K, V в HashMap[K, V].
   • fn Result[T, E] @ok() — T, E.
   • С bound (D72): fn HashMap[K Hash, V] @from_pairs(...).
2. fn[T] префикс (новое, D145) — для receiver’ов без carrier brackets: bare T, []T, tuple (T, U), composite без carrier:
   • fn[T] T @identity() -> T => @ — bare typevar.
   • fn[T] []T @map[U](f fn(T) -> U) -> []U => ... — array.
   • fn[T, U] (T, U) @swap() -> (U, T) => (@1, @0) — tuple.
   • fn[T Hash] []T @dedup() -> []T => ... — bounds через D72.
   • fn[T A + B] []T @method() => ... — multi-bound через + (Plan 101.3).

Правило

Когда fn[T] обязателен

fn[T1, ..., Tn] префикс обязателен для каждого typevar в receiver-position, который не декларируется через carrier-brackets именованного generic-типа. Конкретно:

Запрет дублирования

fn[T] запрещён для typevar, который ТАКЖЕ декларируется через carrier-brackets:

fn[K Hash, V] HashMap[K, V] @method   // ERROR E_DUPLICATE_GENERIC_DECL
// K, V уже декларированы через HashMap[K, V]; используй
// fn HashMap[K Hash, V] @method

Disambiguation: bare T vs named type

Critical: fn []T @method без fn[T] префикса и без type T в scope — type-check error: «T не объявлен ни через carrier-brackets, ни через fn[T] префикс, ни как named type». Закрывает silent-miscompile gap (vec.nv pre-Plan-101 поведение).

Bound syntax (через D72)

fn[T Hash] []T @dedup() -> []T => ...
fn[T A + B] []T @method() => ...                    // multi-bound (Plan 101.3)
fn[K Hash, V] (K, V) @key_value() -> (K, V) => @
fn[T From[K], K] T @construct_from(v K) -> T => T.from(v)   // parametric protocol

Bound = protocol-тип (D72) ИЛИ type-set (D310, Plan 172.3). Type-set — именованное множество конкретных типов (type SignedInt set i8 | i16 | …), используемое как bound: fn[T SignedInt] T.parse(...). Композиция type-set ∧ protocol — через тот же + ([T SignedInt + Hash]): T ∈ set И реализует protocol, проверки независимы per-member; не более одного type-set в одном bound-листе (E_MULTIPLE_TYPE_SETS). Произвольные representation/underlying bounds (~int, structural) — по-прежнему open question Q-representation-bound, Plan 102 (future); D310 закрывает только explicit-member-set, не representation.

Protocol composition (Plan 101.4 — закрывает D53 open question)

Protocols composed через use A, B keyword внутри protocol body. Параллель D39 record-embed (same keyword, разная семантика). Composition валиден в type-decl и anonymous type-position. Literal-position — composition ОТВЕРГНУТА (см. ниже).

type Reader protocol { read(buf []u8) -> int }
type Writer protocol { write(buf []u8) -> int }

// 1. Multi-composition в type-decl:
type ReadWriter protocol {
    use Reader, Writer       // embed
    close() -> ()            // own method
}

// 2. Single-composition (естественно, без ambiguity):
type ReadExt protocol {
    use Reader
    job() -> ()
}

// 3. Pure composition без own methods:
type Streamable protocol {
    use Reader, Writer, Closeable
}

// 4. Mix anywhere в block — order independent:
type Complex protocol {
    init() -> ()
    use Reader
    helper() -> int
    use Writer
}

// 5. Anonymous-composition в type-position (extension D53):
fn process(rw protocol { use Reader, Writer }) { ... }

// 6. Использование как bound — composed protocol работает как named:
fn[T ReadWriter] []T @process() => ...
// эквивалентно fn[T Reader + Writer] []T @process() (101.3 multi-bound)

Семантика:

• use A, B, C — flatten method-signatures из A, B, C в этот protocol.
• Resulting method-set = union(A, B, C, own_methods).
• Multiple use-statements аккумулируются: use A, B; use C ≡ use A, B, C.
• T satisfies composed-protocol ⟺ T has все methods из union.

Реализация ред. 5 (2026-05-25, Plan 101.4):

• Парсер поддерживает обе формы: use A, B (comma-list, как в spec) и use A\n use B (line-per-use, более читаемо в большом protocol’е).
• Все use-items должны идти В НАЧАЛЕ protocol body — interleaving с методами запрещён (E_PROTOCOL_EMBED_AFTER_METHOD). Это упрощает чтение: сначала видишь “состав”, потом “новое”.
• Type-check ловит:
  • E_PROTOCOL_EMBED_UNKNOWN — embed target не объявлен.
  • E_PROTOCOL_EMBED_NOT_PROTOCOL — target существует, но не protocol.
  • E_PROTOCOL_EMBED_CYCLE — A use B ↔ B use A (или self-embed).
  • E_PROTOCOL_EMBED_DUPLICATE — после flatten’а ≥2 method из разных embed-источников с тем же (name, arity). Override-механизм отложен.
  • E_PROTOCOL_EMBED_NOT_NAMED — use <complex type> запрещено.

Literal-composition — отвергнута:

// ❌ ОТВЕРГНУТО:
ro v = protocol Foo {
    use Reader               // error: E_LITERAL_COMPOSITION_NOT_ALLOWED
    read(buf) => impl1
    close() => impl2
}

// Workflow: extract в named type:
type MyRW protocol { use Reader, Writer }
ro v = protocol MyRW {
    read(buf)  => impl1
    write(buf) => impl2
}

Почему literal-composition отвергнута: literal — value-construction (impls), composition — type-level operation. Смешивать слои когнитивно нагружено. Industry-aligned — Rust/Go/Java/Kotlin/Scala не разрешают anonymous-composition в literals.

Asymmetry с multi-bound (101.3) [T A + B] оправдана: разные contexts — multi-bound = use-site intersection при satisfaction-check; protocol composition = decl-time method-set union. Разные scopes, разные операторы.

Differences vs D39 (record-embed):

• D39 record use name Type (field-form, runtime delegation+field).
• D53+ protocol use Type[, Type]* (нет field, compile-time method-set union).
• Same keyword use — same intuition «include this stuff». Parser распознаёт по контексту (record-body vs protocol-body).

Многократное использование одного имени

Одно имя — один generic во всей сигнатуре (existing D119 / D72 convention):

fn[T] (T, T) @duplicate(a T) -> (T, T) => (a, a)   // T дважды → один T
fn[T] [][]T @flatten() -> []T => ...                // T в receiver и return — один T

AMEND (2026-06-14, Plan 153.5 commit 1c323d0e): вложенные generic-ресиверы произвольной глубины

fn[T]-typevar в receiver-position теперь связывается структурной унификацией на ЛЮБОЙ глубине вложенности — не только на верхнем уровне элемента. Это закрывает дыру, из-за которой [][]T @flatten() (= carrier-форма Vec[Vec[T]] @flatten() под D239) не работал: тело должно назвать внутренний T, а компилятор биндил его в непосредственный элемент.

Корень (обе формы записи теряли вложенность до фикса):

• Carrier Vec[Vec[T]] — ПАРСЕР отвергал вложенный тип в carrier-слоте (parse_generic_decl_params ждал parse_ident на каждый слот → «expected ], got identifier»).
• Slice [][]T — ПАРСИЛСЯ, но монорфизатор биндил receiver-typevar T в непосредственный элемент (Vec[int]), не во внутренний (int) — вложенность [][]T схлопывалась в один "[]T"-ресивер → тело строило out []T == Vec[Vec[int]], возвращало неверный тип (verified probe RUN-FAIL, mono’d out = Nova_Vec____Nova_Vec____nova_int_p).

Правило (после AMEND):

• Обе формы записи приняты и эквивалентны под D239: fn[T] Vec[Vec[T]] @m ≡ fn[T] [][]T @m. Парсер несёт полный структурированный тип ресивера в Receiver.receiver_ty (type_name его flatten’ит в "[][]T" и теряет глубину — поэтому нужен отдельный структурный слот).
• Receiver-typevar биндится в самый внутренний элемент, рекурсивно (depth-agnostic): для Vec[Vec[T]]/[][]T T = element-of-element; для Vec[Vec[Vec[T]]]/[][][]T T = element третьего уровня; и так далее. Унификация — структурная (по форме типа), не one-level-hardcoded.
• Свободные typevar’ы collect’ятся рекурсивно из вложенного carrier-слота для проверки E_UNUSED_PREFIX_TYPEVAR (typevar объявлен в fn[T], но не упомянут в ресивере → ошибка) — собираются из receiver_ty, а не из flatten’енного имени.
• E_UNDECLARED_TYPEVAR_IN_RECEIVER сохраняется для fn []T @m / fn [][]T @m без fn[T]-префикса (scope-typevar НЕ сидится из receiver_ty — это намеренно, иначе ошибка маскировалась бы; см. checker-заметку).

fn[T] [][]T @flatten() -> []T => ...                // T = innermost (depth 2) — РАБОТАЕТ
fn[T] Vec[Vec[T]] @flatten() -> Vec[T] => ...       // carrier-форма, ≡ выше под D239
fn[T] [][][]T @deep_count() -> int => ...           // depth 3 — T = innermost
fn[T] [][]T @first_row() -> []T => ...              // вложенный-типизированный return

Реализация (depth-agnostic, без one-level-hardcoding):

• AST — Receiver.receiver_ty: Option<TypeRef> несёт полный структурированный тип вложенного ресивера (единственное место, где глубина переживает — type_name flatten’ит в "[][]T").
• Parser — slice [][]T: счёт глубины Array + спуск до внутреннего Named → строит Array(Array(Named T)). Carrier Vec[Vec[T]]: новый разбор принимает ВЛОЖЕННЫЙ parse_type в слоте (детект Ident[) + рекурсивный сбор free-typevars; структурные слоты сворачиваются в receiver_ty. Free-fn [T Bound=D]-разбор не тронут.
• Mono — переиспользован существующий рекурсивный infer_type_param_binding для структурного бинда receiver-typevar (Array-арм также снимает mono-форму Vec____, восстанавливая элемент через generic_type_instance_info); override применён на ВСЕХ путях, биндящих receiver-typevar (emit-dispatch carrier + []T-sentinel slice + call-site return-inference). Depth-aware sentinel-ключи "[]"*N+"T" заменили hardcoded "[]T". Flat []T (depth 1) остался byte-identical (legacy NovaArray_-путь); override гейтится receiver_ty_is_nested — только для реально вложенных ресиверов.
• Checker — вложенные typevar’ы из receiver_ty собираются в referenced-множество для E_UNUSED_PREFIX_TYPEVAR; scope gs НЕ сидится из receiver_ty (сохраняет E_UNDECLARED_TYPEVAR_IN_RECEIVER — verified, что seed был бы регрессией).

Cross-cutting заметка. Это путь, через который идут ВСЕ []T-методы stdlib (slice- dispatch). Изменение специально гейтнуто на genuinely-nested ресиверы → flat-случай неизменен. См. D263 AMEND (@flatten использует этот фундамент).

Известное ортогональное ограничение (pre-existing, вне scope): slice-форма fn[T] [][]T -> []T, чьё тело строит свежий Vec[T].new(), упирается в pre-existing erased-base-body лимит, который ЛОМАЕТ и flat fn[T] []T с Vec[T].new() на baseline (expected struct 'Vec____Nova_T_p'). Production-flatten — CARRIER-форма Vec[Vec[T]] @flatten (как все stdlib), работает полностью; slice-form nested-receiver binding доказан отдельно (@count_all/@first_row).

Backward-compat

• 100% преserve для existing fn Option[T] @map[U], fn HashMap[K, V] @keys, fn Result[T, E] @ok, fn HashMap[K Hash, V] @method — D145 строго аддитивно.
• std/collections/vec.nv содержит 7 методов pattern fn []T @method[U] (написан как-если-бы T дженерик). Это bug — T silently трактуется как named type, codegen падает. Plan 101.1 включает migration vec.nv → fn[T] []T @method[U].

Параллель индустрии — таблица

Nova edge:

1. Cleanest receiver syntax — fn[T] []T @map короче Rust impl<T> Vec<T> { fn map<U> } (2 nested blocks → 1 line).
2. Bound syntax без двоеточия — [T Hash] (D72) — параллель Nova name type convention (params, fields, let).
3. Multi-bound + familiar — Rust audience узнаёт.
4. Protocol composition через use — параллель D39 record-embed, единое правило.
5. Loud disambiguation — E_BARE_TYPEVAR_NEEDS_PREFIX / E_PREFIX_SHADOWS_NAMED_TYPE явные, не silent miscompile.
6. Future-proof — Q-representation-bound открыт для extension на concrete-type bounds (Plan 102).

Lineage

• Plan 48 / D119 — method-level + receiver-via-carrier generics.
• Plan 72 / D72 — bound syntax [T Bound] (free fn + type-decl). D145 переиспользует в новой позиции (fn[T Bound] prefix).
• Plan 88 — static-method-on-typevar.
• Plan 99 — Option/Result closure-applying на Nova-body (paritет).
• D39 — use Type embed для records. D145 переиспользует pattern для protocol composition (Plan 101.4).
• D53 — type X protocol { ... }. D145 закрывает open question «Composition protocol’ов» через 101.4.

См. также

• D72 — bound syntax.
• D119.
• D39 — use для embed.
• D53 — protocol decl.
• Plan 101 master
  • 5 sub-plan’ов:
  • 101.1 — core fn[T] grammar + codegen + vec.nv migration (P1, blocker Plan 91).
  • 101.2 — bound integration fn[T Hash].
  • 101.3 — multi-bound [T A + B], closes Q-multi-bound.
  • 101.4 — protocol embedding use Foo, closes D53 open question.
  • 101.5 — stdlib audit + LSP + close.
• Q-representation-bound — concrete-type bounds (newtype/embed-aware), Plan 102 future.

D372. Canonical .new() constructors (convention)

Статус: convention (stdlib provides, compiler does NOT auto-generate).

stdlib предоставляет .new() для типов с единственным очевидным default-значением: