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 — две эквивалентные формы:

AMEND 2026-09-28 (D486 §3): неявная форма РЕТРАКТИРОВАНА. .. обязателен при частичном списке полей во ВСЕХ позициях — match, биндинг, if/while-let, for (E_RECORD_PATTERN_NEEDS_REST). Текст ниже сохранён как история решения.

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

// неявная — без маркера, остальные поля игнорируются
// ОТМЕНЕНО D486 §3: сегодня это E_RECORD_PATTERN_NEEDS_REST
match @buckets[idx] {
    Occupied { value } => Some(value)
    _                  => None
}

Явная форма — visual cue «здесь ещё поля». Неявная — краткость. Действует только явная форма (D486 §3).

Переименование при деструктуризации остаётся явным: 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 — префиксы полей (ro, mut) и group-syntax внутри record.

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

Уточнено D326 (2026-10-03, решение владельца): newtype над кучевым типом сам кучевой для правила mut-параметра (Р3): представление — основы. Уточнено D156 (2026-10-03, решение владельца): newtype над must-consume типом (type Tx2 Tx при type Tx consume …) сам must-consume — обёртка из одного значения, линейность наследуется, как у контейнера.

⚠️ 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] [consume] [value] [priv|priv(type)] { … }

Модификаторы комбинируются — в единственном каноническом порядке D241 (consume → value → priv): export type Job consume value priv { … }.

Поля внутри {…} могут иметь 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

Амендмент 2026-10-02 (решение владельца; вопрос облачной сессии p274-carina-cast): конструктор newtype принимает значение ПРЕДСТАВЛЕНИЯ, а не самого newtype. W(e) при type W int законно, когда e — int (или литерал, D489). Если e уже типа W, это ошибка E_NEWTYPE_CTOR_SELF с подсказкой «e уже W — конструктор не нужен»: повторная обёртка либо пустая операция, либо знак того, что автор считает e значением представления. Доноры — Rust (конструктор tuple-struct принимает внутренний тип) и Swift; Go разрешает конверсию в тот же тип, у нас — нет, как нет и прочих неявных превращений. Оракул на 2026-10-02 принимает W(e) при e W как тождество — реестр 221.1 №1596.

Альтернативу 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 — префиксы полей (ro, 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. Закрыто (Plan 200, 2026-07-12) — D55 §Obvious single-wrapper coercion: литерал и нетипизированная константа (ro u UserId = 42, 40 + 2) оборачиваются сами; переменная — только явно, UserId(n) или n as UserId (D55, амендмент 2026-08-21, решение владельца; прежняя фраза «binding авто-коэрсится так же» снята 2026-10-02 как противоречащая ему).

Эволюция

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

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

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

Амендмент (ОКНО-5, 2026-07-23): newtype над fn-типом + call-through + alias-прозрачность

Проблема. type Handler fn(ServerRequest) -> ServerResponse (newtype, underlying — fn-тип) не парсился: expected identifier, got '('. Причина — parser-эвристика «пустой sum» (empty-sum body-end detection, см. Plan 72 P1-B выше) трактовала ЛЮБОЙ голый KwFn сразу после type X как начало СЛЕДУЮЩЕЙ top-level декларации (type X без тела + отдельная fn name(...)), а не как начало fn-типа. Настоящий top-level fn ВСЕГДА несёт identifier сразу после keyword (fn name(); fn-TYPE body, наоборот, начинается fn( — сразу (, без имени. Однозначный lookahead одним токеном: fn считается концом декларации (следующая fn-декларация) ТОЛЬКО когда токен ПОСЛЕ него — НЕ (.

Форма (закрывает синтаксический пробел, D52 §Полный синтаксис остаётся без изменений — это РАСШИРЕНИЕ newtype-формы type X Y, где Y теперь может быть fn-типом, не только именованным типом):

type Handler fn(ServerRequest) -> ServerResponse   // newtype над fn-типом
type HandlerAlias alias fn(int) -> str             // alias fn-типа (тоже валиден)

Call-through (единственный newtype-род, форвардящий операцию над underlying). Значение newtype-над-fn-типом вызывается НАПРЯМУЮ:

fn call_it(h Handler, req ServerRequest) -> ServerResponse => h(req)

Обоснование — асимметрия с int-newtype (UserId), который НЕ форвардит +: вызов — ЕДИНСТВЕННАЯ осмысленная операция над значением функционального типа (в отличие от арифметики, у которой для домена UserId попросту нет единственно верной трактовки). Прецедент — Go type HandlerFunc func(...), который одновременно и вызывается (h(w, r)), и несёт методы. Newtype как имя ОСТАЁТСЯ (методы, внятная диагностика «ожидался Handler», типы не путаются) — call-through не отменяет nominal-типизацию, просто добавляет ОДНУ разрешённую сквозную операцию.

Alias fn-типа — прозрачность включает вызов. До этого амендмента type X alias fn(A) -> B объявлялся без ошибок, но значение типа X не вызывалось ([E_CALL_NOT_CALLABLE]) — резолв вызова смотрел на ИМЯ типа локала, не разворачивая alias. D52 alias уже требует полной прозрачности (X и Y совместимы) — вызываемость теперь часть этой прозрачности, разворачивается ТРАНЗИТИВНО через любую цепочку alias’ов.

Авто-коэрсия fn → Handler. См. D55 §Obvious single-wrapper coercion — fn-типы добавлены в структурную «таблицу родов», используемую тем же механизмом, что и int/str/[]u8 (никакого нового кода coercion-стороны не потребовалось — механизм уже был обобщён на произвольный Newtype(inner), не только скалярный inner). Однонаправленно: Handler → fn НЕ коэрсится (nominal-типизация не растворяется — два РАЗНЫХ newtype над ОДНИМ fn-типом взаимно неподставимы, см. регресс d52_newtype_fn_reverse_coerce_neg.nv).

Известный, задокументированный остаток (НЕ в объёме амендмента): два overload’а, различающихся ТОЛЬКО newtype-fn-параметром с ОДИНАКОВОЙ underlying-сигнатурой, и вызов с голой fn-функцией — checker НЕ детектирует двусмысленность на Nova-уровне (тот же класс, что и pre-existing [M-172.1-free-fn-multi-overload-ambiguous]); компиляция падает ЧЕСТНО, но на C-уровне (мангл-коллизия, оба erased-параметра — void*) — см. регресс d55_fn_newtype_ambiguous_lift_neg.nv (EXPECT_CC_ERROR, НЕ EXPECT_COMPILE_ERROR). Отдельно найден, ОРТОГОНАЛЬНЫЙ newtype-у, pre-existing пробел: assignable_direct для fn-типизированного expected коллапсирует категорию в Any (структурная проверка fn-сигнатур на call-arg позиции отсутствует ВООБЩЕ, для любого fn-значения, newtype или голого) — заведено как [M-fn-type-expected-any-bypass] в docs/plans/backlog-followups.md, вне объёма этого окна.

Реализация: compiler-codegen/src/parser/mod.rs (parse_type_decl empty-sum lookahead), compiler-codegen/src/types/mod.rs (BoundCtx::fn_type_names pre-scan + check_call_callee_not_local_shadow), compiler-codegen/src/codegen/emit_c.rs (fn_newtype_sigs pre-scan + resolve_fn_typeref — call-dispatch через существующий NovaClosBase/ NOVA_CLOS_CALL_* механизм, ноль нового codegen). Регресс: spec_tests/conformance/d52_newtype_fn_type.nv (4 куска) + spec_tests/conformance/neg/d52_newtype_fn_reverse_coerce_neg.nv + spec_tests/conformance/neg/d55_fn_newtype_ambiguous_lift_neg.nv.

Амендмент (2026-09-04, решение владельца): операторы над числовым newtype — только внутри одного newtype

Что обнаружено (исследование docs/dev/research/2026-09-04-typed-index-vec.md, реестр строка «операторы стирают newtype», проба docs/plans/repro/904-newtype-operators-erase/). Newtype объявлен «типизированно отличным от Y, Go-style» (§Что), и вызовы это соблюдают: fn f(r FnRow) отвергает аргумент TyId (E7301). Но бинарные операторы — нет: FnRow == TyId, FnRow < TyId, FnRow + TyId и FnRow + n при n int проходят чекер, собираются и исполняются (печатают true false 2 true 2). Различие newtype компилятор знает и применяет на одной двери (вызов), а на другой (оператор) стирает. Ни этот блок, ни D46 (операторы через @-методы) случай не описывали.

Норма. Для newtype X над числовым представлением Y:

1. Бинарные операторы арифметики (+ - * / %) и сравнения (== != < <= > >=) определены между операндами одного и того же newtype X. Результат арифметики — X; результат сравнения — bool.
2. Числовой литерал в позиции операнда адаптируется к X (как и при присваивании, Plan 200): a + 1 при a FnRow законно, результат FnRow.
3. Смешение операндов — X с другим newtype Z, X с значением типа Y (переменная, поле, результат вызова) — compile error; диагностика называет явный as как путь: a + (n as FnRow) или (a as int) + n, по смыслу места.
4. Унарные операторы и составные присваивания (-a, a += b) — по тем же правилам.

Это ровно семантика донора: в Go type FnRow int даёт FnRow == TyId → mismatched types, FnRow + 1 законно (untyped constant), FnRow + n при n int → ошибка.

Почему (а), а не «стирание намеренно». Смысл newtype над числом — чтобы два пространства номеров нельзя было спутать; самое частое место такой путаницы — сравнение if row_id == ty_id. Стирание в операторах оставляло бы гарантию newtype дырявой ровно там, где она нужнее всего, и обесценивало бы типизированные индексы (IndexVec[I, T], то же исследование): защита на [] и вызовах ничего не стоит, если индексы можно сравнить между собой напрямую.

Реализация (требование): операнды оператора проверяются той же дверью, что аргументы вызова — не второй копией сверки; иначе дыра вернётся при следующем операторе. Запись положена до фикса: спека прежде реализации. Фикстуры — у чинящего: негатив на ==/</+ между двумя newtype и между newtype и Y-переменной (line-pinned), позитив на операторы одного newtype с результатом того же типа и на литерал.

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
• D478 — как читается имя варианта, написанное БЕЗ имени типа

D478. Разрешение ГОЛОГО имени варианта: по ожидаемому типу, иначе квалификация (2026-09-16) {#d478}

Статус: ПРИНЯТО (решение владельца 2026-09-16; поднято окном Карины, план 274.7 волна В14). Дополняет D406 — тот задаёт СИНТАКСИС сумм, этот блок отвечает на другой вопрос: как читается ИМЯ варианта, написанное без имени типа.

Задача

Две суммы в области видимости могут объявить вариант с одним именем:

type Color  enum Red | Green
type Signal enum Red | Amber

До этого решения язык на вопрос «что значит голое Red» не отвечал вовсе, и две реализации разошлись: нынешний компилятор принимал такую программу, выбирая сумму сам (реестр 221.1 №962, №964 — выбирал он её неверно), а Карина отвергала любое голое имя, видимое дважды. Пробы обеих половин лежат в docs/plans/repro/b14-d406-rejected/.

Правило

1. Имя варианта, видимое РОВНО ИЗ ОДНОЙ суммы, разрешается в неё. Квалификация не требуется, и существующий код не меняется — это большинство случаев.
2. Имя, видимое из ДВУХ И БОЛЕЕ сумм, разрешается ПО ОЖИДАЕМОМУ ТИПУ позиции. Ожидаемый тип — это тип, ОБЪЯВЛЕННЫЙ в самой программе для этой позиции, а не выведенный из соседних выражений.
3. Если ожидаемого типа у позиции нет — это ошибка, и она требует квалификации Type.Variant. Не «выбрать любую», не «выбрать первую объявленную»: молчаливый выбор из двух и есть то, что уже дало дефект №964.

Что считается ОЖИДАЕМЫМ ТИПОМ — закрытый перечень позиций

Перечень закрыт по построению: тип объявлен синтаксически, значит позиция либо объявляет его, либо нет. Ожидание есть у:

• хвоста и return функции с объявленным типом возврата;
• аргумента вызова, у чьего параметра объявлен тип;
• биндинга с объявленным типом — ro c Color = Red;
• поля в конструкторе записи — тип поля объявлен в типе;
• ветви match/if, стоящей в значащей позиции из перечисленных — ожидание протекает внутрь ветвей, потому что ветвь и есть значение этой позиции.

Ожидания НЕТ, и потому требуется квалификация, у:

• биндинга без объявленного типа — ro c = Red;
• элемента литерала массива без объявленного типа элемента;
• операнда сравнения или арифметики, когда вторая сторона тип не фиксирует;
• выражения-утверждения, значение которого отбрасывается.

Отказ

Диагностика обязана назвать ОБЕ суммы и потребовать форму Type.Variant. Сообщение «имя объявлено более чем одной суммой» без имён сумм заставляет читателя искать их самому — а он и так уже не знает, какие это суммы.

Примеры (обе половины — из проб волны В14, не выдуманы)

module probe.d478

type Color  enum Red | Green
type Signal enum Red | Amber

fn pick() -> Color {
    Red                    \ ЗАКОННО: ожидаемый тип объявлен возвратом
}

fn main() {
    ro c = Red             \ ОШИБКА: ожидания нет -- писать Color.Red
    ro s Signal = Red      \ ЗАКОННО: тип биндинга объявлен
    println("ok")
}

Что этот блок НЕ решает (границы)

• Не вводит вывод типа по соседям. Ожидание берётся только из объявления; «понятно из контекста» без объявления — не основание, иначе правило перестанет быть проверяемым.
• Не трогает квалифицированную форму. Color.Red законна всегда и была законна до этого блока.
• Не отменяет дефекты реализаций: нынешний компилятор выбирал сумму неверно (№962, №964) — это чинится отдельно и к формулировке правила отношения не имеет.

Связь

• D406 — синтаксис объявления сумм;
• реестр 221.1 №962, №964 — дефекты разрешения по голому имени в обеих реализациях;
• план 274.7, волна В14 — отказ Карины AMBIGUOUS_VARIANT_MSG после этого блока становится ЧАСТИЧНО неверным (он отвергает любое голое имя, видимое дважды, даже когда ожидаемый тип есть) и требует работы, а не переезда.

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
    @equal(other Self) -> bool
}

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

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

type Iterator[T] protocol {
    mut @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-блоке: @ ОБЯЗАТЕЛЕН

НОРМА (D209, Plan 108.4). У instance-метода в объявлении протокола префикс @ обязателен; голое имя — ошибка разбора E_PROTO_METHOD_NEEDS_AT («add @ before method name»). Статический метод пишется ТОЧКОЙ. Модификатор приёмника стоит ПЕРЕД @, по умолчанию он ro:

type Hash protocol {
    @hash() -> u64                   // instance, приёмник `ro` по умолчанию
    @equal(other Self) -> bool
}

type Iter[T] protocol {
    mut @next() -> Option[T]         // mut-приёмник
}

type FromIter[T] protocol {
    .from_iter(it Iter[T]) -> Self   // static — через точку
}

Грамматика и полный список ошибок соответствия реализации — D209.

ОТМЕНЕНО D209 (Plan 108.4, 2026-06-09). Здесь стояло правило, что в protocol-объявлении instance-методы можно писать в ОБЕИХ формах — с @ и без, — и что они эквивалентны:

type Hash protocol {
    hash() -> u64                    // голое имя — БОЛЬШЕ НЕ ПРИНИМАЕТСЯ
    eq(other Self) -> bool
}

Довод был: в protocol-блоке метод всегда instance, контекст однозначен, поэтому @ факультативен; выбор предлагался по вкусу — «с @ ради симметрии с реализацией, без @ ради краткости». Исключением уже тогда были mut-методы: mut @next() требовал @, потому что голое mut next() двусмысленно с mut-binding’ом.

Чем отменено: D209 сделал @ обязательным и добавил модификаторы приёмника (mut/ro/consume) с проверкой соответствия реализации; тогдашнее исключение для mut-методов стало общим правилом. Вопрос Q-protocol-method-prefix закрыт ЭТИМ решением, а не прежней секцией.

Правка редакционная (2026-09-16, окно Карины, приказ владельца; форма — интегратора, согласована по /peers). Раздел стоял с 2026-05-08 и показывал голую форму как законную — то есть спека учила писать то, что компилятор отвергает ошибкой разбора. Норма не менялась и rev не выдавался: текст приведён к решению D209. Тем же проходом @ дописан в 32 объявлениях протоколов по всей спеке, причём ТРИ статических метода получили точку, а не @ (строка реестра №1144).

Реализация в 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.

D53 amend (2026-07-20, [M-checker-protocol-typed-arg-any-bypass], worktree nova-protoany) — PLAIN protocol-typed параметр требует СТРУКТУРНОГО соответствия

Status: ACTIVE. Язык-меняющее по строгости (то, что раньше молча проходило, теперь — compile error).

Что было

Строка 940 этой же секции (log_one(my_user) // ok, User совместим со Display) документирует PLAIN (не-generic-bound) protocol-typed параметр как «type value / existential» — заявленный, легальный способ использовать protocol (D53 сам называет его прямо, наравне с generic-bound-формой). Но checker-реализация (resolved_cat_of_depth, compiler-codegen/src/types/mod.rs) мапила любой TypeDeclKind::Protocol expected-тип в ResolvedType::Any — permissive-коллапс, унаследованный от старого cat_of («protocol/effect/opaque permissive»), появившийся ДО структурной protocol-машинерии (D53/D72/D142) и никогда не пересмотренный. Из-за этого assignable_direct пропускал любой аргумент в PLAIN protocol-typed позицию БЕЗ проверки, что аргумент реально реализует протокол — структурная типизация (§«Структурная совместимость») энфорсилась только для generic-bound-формы ([T Protocol], отдельный механизм — BoundCtx::check_satisfaction, D72/D142), никогда для голого x Protocol.

Симптом-прецедент: Fmt = protocol { use Write, @width()..., ... } (D422), StringBuilder реализует только Write (embedded под-протокол), НЕ полный Fmt — но .debug(sb)/.display(sb) с sb: StringBuilder компилировался БЕЗ ошибки (вместо корректного «нужен FmtCtx.bare(sb, ...)», см. d374_write_sink_decouple.nv). На C Nova_StringBuilder* шёл туда, где ожидался Nova_FmtCtx* (оба — указатель на offset 0) → тихая type confusion (пустая строка) вместо чистой compile-error.

Что теперь

assignable_direct СТРУКТУРНО проверяет PLAIN protocol-typed позицию — той же проверкой «имя+арность метода присутствует (прямо, через use-embed (D145) рекурсивно, или через default_body-фолбэк, D183)», что generic-bound-форма уже применяет. Несоответствие → чистая compile error (переиспользует существующие коды [E7301]/[E_NO_MATCHING_OVERLOAD] — новый код ошибки не заводился). Соответствующий аргумент по-прежнему проходит — правило log_one(my_user) (строка 940) не изменилось, изменилось только то, что НЕсоответствующий аргумент больше не проходит молча.

Не затронуто (намеренно, риск-контейнмент): resolved_cat_of_depth сам НЕ менялся (Any-коллапс для protocol остаётся — используется другими consumer’ами); generic-bound путь (BoundCtx) не менялся — уже был корректен; protocol-литералы (expression-position, protocol Name { ops }, D142) не проверяются этим правилом — их completeness уже проверяется на месте конструкции (missing-method там уже была compile error, neg_protocol_lit_missing_method.nv).

Гейт: spec_tests/conformance standalone single-CU 508 PASS / 0 FAIL / 14 SKIP (baseline 504/0/14 + 4 новых neg/neg_protocol_param_* фикстуры). Реализация — protocol_mismatch_found/protocol_required_missing/protocol_missing_methods (compiler-codegen/src/types/mod.rs, рядом с assignable_direct). Подробности — backlog-followups.md → [M-checker-protocol-typed-arg-any-bypass].

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

Уточнено D491 (2026-10-02): обёртка значения в вариант суммы сверяет ЧИСЛОВОЙ тип точно (int ≠ i64); «int-семья взаимозаменяема» снята.

Уточнено D489 (2026-10-02): тип литерала в позиции — единое правило литерала (пункт 4 и амендмент 2026-09-04 читаются через него).

Уточнено D488 (2026-10-01): размещение и передача значения (в т.ч. вид str → ro []u8 из подраздела ниже: заголовок вида на стеке вызывающего, без аллокации в любой позиции) — там единственный дом правила.

Что

В позиции, где компилятор явно знает целевой тип 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.

Амендмент 2026-09-04 (решение владельца; исследование docs/dev/research/2026-09-04-numeric-widening.md §3, пробы docs/plans/repro/926-mixed-numeric-doors/float_lit_ok, float_lit_neg). Пункт 4 перечислял только целые цели; компилятор при этом уже принимал ro x f32 = 1.5 и b + 1 при b f64 (печатает 3.5 1.5) и отвергал ro n int = 1.5 (E7301) — поведение разумное, но не записанное. Записывается:

• Float-литерал (с точкой или экспонентой) в позиции float-типа (f32, f64) принимается без as — продолжение правила для целых; f32 получает ближайшее IEEE-значение. В позиции целого типа — по-прежнему ошибка (E7301), без сужения.
• Литерал без точки — «число», а не «целое», пока у него нет типа. В позиции float-типа и в операнде числового оператора против float-операнда он адаптируется к этому float-типу: b + 1 при b f64 есть b + 1.0. Донор здесь Go (untyped constant), не Rust (там нужно 1.0): D55 уже трактует литерал как подгоняемый под цель, и запрет дал бы 1.0 ради формы, не смысла.
• Оба правила касаются только литералов. Значения типа int/f32 с float-операндом другой ширины — по-прежнему ошибка (D405, амендмент 2026-09-04): одинаковый конкретный тип, явный as.

Амендмент 2026-10-02 → D489. Какой тип литерал получает в позиции и когда это ошибка — теперь одно правило в своём блоке; пункт 4 и амендмент 2026-09-04 выше читаются через него.

Амендмент 2026-10-01 (интегратор; реестр 221.1 №1517, ветка p1517-variant-ctor-check). Конструктор варианта в позиции с явным типом судится по тому же правилу, что и литерал, — в check, а не в C:

• payload сверяется с ИНСТАНСОМ ожидаемой суммы. fn bad() -> Option[str] => Some(1) — E7301: Option[int] и Option[str] — разные инстансы (D405), и поле варианта инстанса Option[str] есть str.
• число значений payload — как в объявлении варианта. Some(1, 2) — E_VARIANT_CTOR_ARITY.
• конструктор без какого-либо источника типа — отказ. Голое None или Err(e) в биндинге без аннотации (ro x = None) не получает тип «по умолчанию»: E_VARIANT_CTOR_UNTYPED, лечится аннотацией. Payload, из которого параметр выводится (ro x = Some(1) → Option[int]), источником типа является.

Донор — вывод по ожидаемому типу на месте, без вывода из последующего использования: у литерала его нет и в пунктах 1–4. Родня, ещё открытая: №1528 (инстанс из переменной), №1529 (обёртка Option по пункту 1), №1531 (ro x = []).

// 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) для record-coercion помечена ⛔ — coercion анонимного {...} на элементах массива пока не работает. Пример станет валиден после расширения Ф.3a на element-positions (за scope Plan 52). Пока там нужен [User{...}, ...] с явным именем типа на каждом элементе.

sum/newtype element-position — реализовано (Plan 200, 2026-07-12), см. «Obvious single-wrapper coercion» ниже. ro args []SqlValue = [1, "alice", true] работает без SqlValue.Int(1)-обёрток — это отдельный, более узкий, механизм от record element-coercion выше (годится ровно для one-level sum-variant/newtype wrap, не для произвольных record- литералов).

Запрет дублирования имени типа (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
    | Int(int) | I8(i8) | I16(i16) | I32(i32) | I64(i64)
    | U8(u8) | U16(u16) | U32(u32) | F32(f32) | F64(f64)
    | Text(str) | Bool(bool) | Bytes([]u8) | Null

ro args []SqlValue = [42, "alice", true]    // [Int(42), Text("alice"), Bool(true)]

// В sql`...` тэге интерполяции тоже оборачиваются, каждое значение — в вариант
// СВОЕГО типа: int → Int, i32 → I32, str → Text, bool → Bool
ro q = sql`SELECT * FROM users WHERE id = ${42}`   // args = [Int(42)]

ro n = 1
ro id i32 = 7
ro q2 = sql`UPDATE t SET name = ${"alice"} WHERE id = ${id} LIMIT ${n}`
// args = [Text("alice"), I32(7), Int(1)] — без единой ручной обёртки
// (варианты по числовым типам — решение владельца 2026-10-02, реестр 221.1 №1637;
// у `u64`/`uint` варианта нет: в 64-битное знаковое целое базы они не входят)

Obvious single-wrapper coercion (D55 amend, Plan 200, 2026-07-12)

АМЕНДМЕНТ 2026-08-21 (решение владельца) — NEWTYPE-ПОЛОВИНА СУЖЕНА ДО НЕТИПИЗИРОВАННЫХ КОНСТАНТ. Это ОТМЕНА части решения 2026-07-12, а не его уточнение.

Правило ниже читается с одной поправкой: пункт 1 (newtype) применяется ТОЛЬКО к нетипизированной константе — литералу, унарной операции над константой и арифметике констант (40 + 60). Типизированная переменная и любое выражение над ней требуют явной формы: W(expr) или expr as W. Пункт 2 (sum) действует БЕЗ ИЗМЕНЕНИЙ, включая переменные.

Почему половины разошлись. В сумму коэрсия ВЫВОДИТ тег: подходящий унарный вариант ровно один, и автор написал бы ровно то же самое (SqlValue.Int(1)). В newtype коэрсия ПРИДУМЫВАЕТ утверждение — «это число есть строка реестра», — а требовать именно этого утверждения newtype и заводят. Обёртка, которая надевается сама, обёрткой не является.

Граница взята у Go, на который D52 ссылается прямо («привычнее программистам с фоном Go»): неявно конвертируется нетипизированная константа, типизированная переменная — нет. Форма была заимствована в 2026-07-12, а граница сдвинута; замер 2026-08-21 показал цену: ro i int = 7; take_row(i) и take_row(i + 1) принимались молча, то есть в доменную обёртку втекало любое целое.

Цена перехода измерена, а не оценена (2026-08-21): скалярных newtype (type X int-форма) — НОЛЬ в std/src и НОЛЬ во всех пакетных репах (nova-http, nova-tls, nova-polaris, nova-compress, nova-bignum, nova-socks, nova-comments); в examples две декларации (orm_demo: UserId, PostId), и обе уже пишут id as UserId явно. Единственным носителем прежнего поведения был сам корпус — фикстура spec_tests/conformance/d55_literal_coercion.nv, перевёрнутая тем же слиянием, плюс новая негативная spec_tests/conformance/neg/d55_newtype_var_coercion_neg.nv.

Выход для автора, которому нужна прежняя мягкость, — D429 #coerce: пара Y → W объявляется в .nv, как объявляется str → ro []u8. Правило R11 (запрет дубля с встроенной обёрткой) с этим амендментом для newtype больше не срабатывает — иначе правило ужесточили бы, а дверь оставили запертой; для суммы R11 действует по-прежнему.

Честно о доктрине: вводная D429 называет «single-wrapper вкл. переменные» частью доктрины «безопасных, очевидных, zero-cost конверсий». Этот амендмент ту доктрину для newtype-половины пересматривает: она написана для доменных обёрток в пользовательском коде и не рассматривала случай, ради которого newtype и понадобился в компиляторе, — РАЗВЕДЕНИЕ ПРОСТРАНСТВ ИНДЕКСОВ, где втекающий голый int и есть тот самый дефект.

Уточнение и расширение sum-coercion, закрывающее компилятор-gap (не только «литералы», но и переменные и любые выражения, принимаемые чекером по этому правилу — см. «Какие выражения оборачиваются» ниже; не только sum, но и newtype — см. открытый вопрос в D52):

Значение выражения expr в позиции с явным ожидаемым типом W авто-оборачивается, если W — ровно одна из двух форм «обёртки над значением», и КАНДИДАТ однозначен:

1. Newtype (type W Y, D52) — expr того же структурного «рода» (см. ниже), что и Y → expr as W (компилятор вставляет as-cast автоматически; newtype — та же C-repr, что и Y, поэтому это zero-cost, не runtime wrap).
2. Sum с ровно одним unary-вариантом C(Y), чей Y совпадает по «роду» с типом expr → W.C(expr) (как ручная форма SqlValue.Int(1), которую авторы писали раньше вручную).

Совпадение по «роду»: f32/f64, bool, str, []u8/Vec[u8], именованный тип по имени; для ЧИСЕЛ — ТОЧНЫЙ тип значения (int ≠ i64, решение владельца 2026-09-10; D491): int-переменная в вариант с i64-payload’ом не оборачивается — пишется n as i64. Литерал же типа не имеет и берёт тип payload’а по D489: если вариант его семьи (целый payload — для целого литерала, f32/f64 — для дробного) ровно один, литерал уходит в него, когда представим ТОЧНО. Если таких вариантов несколько, литерал берёт тип по умолчанию D44 — int для целого, f64 для дробного — и оборачивается в вариант с payload’ом ровно этого типа (ro v SqlValue = 1 — Int(1), ${1.5} — F64(1.5)); варианта с таким payload’ом нет — коэрсия неоднозначна, обёртки нет, действует прямая проверка типов. (Решение владельца 2026-10-02, реестр 221.1 №1637.) Прежняя фраза «int-семья взаимозаменяема, ширина доводится as-cast’ом, „прячет“ int→i64 widening» снята 2026-10-02 как противоречащая D405/D491. Int и float — РАЗНЫЕ «роды», иначе ${1} был бы неоднозначен между I(i64)/F(f64) и ничего бы не обернулось; то, что реализация (cat_compatible_rt) сегодня пропускает значение float в целую позицию и обратно, — дефект (реестр 221.1 №1611), а не норма.

Амендмент (ОКНО-5, 2026-07-23): fn-типы в таблице родов. Род Fn добавлен для структурного совпадения fn(A, …) -> R с fn(A, …) -> R (параметры и возврат совпадают структурно) — тот же механизм, что и для int/str, БЕЗ отдельного нового кода: single_wrap_candidates уже был обобщён на произвольный Newtype(inner) (не только скалярный inner), а WrapKind::Other-fallback для TypeRef::Func УЖЕ различал fn-значения от не-fn (единственный практический сценарий этого амендмента — type Handler fn(A) -> B с ОДНИМ таким newtype в скоупе — уже корректно разрешался существующим кодом; расширение зафиксировано here как явное намерение, а не побочный эффект). Пример:

type Handler fn(ServerRequest) -> ServerResponse

fn make_response(req ServerRequest) -> ServerResponse => { body: "hi" }
fn accept(h Handler) -> str => "ok"

ro r = accept(make_response)   // fn -> Handler, авто-подъём

Как и для int/str — однонаправленно: Handler → fn (или Handler → Middleware, другой newtype над ТЕМ ЖЕ fn-типом) НЕ коэрсится — единственный существующий механизм (single_wrap_candidates) ключуется ТОЛЬКО по expected-стороне и всегда ОБОРАЧИВАЕТ голое значение в именованную обёртку, никогда не разворачивает названную обёртку обратно (нет и не было обратной ветки). Регресс: spec_tests/conformance/neg/d52_newtype_fn_reverse_coerce_neg.nv. См. D52 §Амендмент (ОКНО-5) для call-through/alias-прозрачности этого же newtype-рода.

Однозначность обязательна: если ⩾2 кандидата совпадают по «роду» (гипотетический sum с двумя int-payload’ами) или 0 совпадают — auto-wrap НЕ срабатывает, экспрешн остаётся как есть (существующая ошибка/поведение).

Ровно один уровень — кандидат-обёртка НЕ разворачивается рекурсивно: int → UserId → Wrapper (обёртка над обёрткой) остаётся отвергнутой (нужен явный промежуточный cast/конструктор). Аналогично — значение без явной целевой типизации (ro x = "test" — тип str, никакой обёртки) coercion не касается: правило работает только там, где target-тип явно известен (см. таблицу позиций выше — let/const, return, call-arg на РЕЗОЛВЛЕННОГО callee, element-позиция []T/Vec[T]).

Явный конструктор (SqlValue.Int(1), n as UserId) остаётся валиден без изменений — значение УЖЕ целевого типа W, поэтому обёртка не запускается (дважды не оборачивается). Форма выражения здесь ни при чём: обёртка не ставится потому, что тип выражения уже W, а не потому, что выражение — не «голый» литерал/Ident.

Какие выражения оборачиваются (уточнение 2026-10-01). Sum-половина правила применяется к любому выражению, которое проходит проверку D55, — то есть чей тип совпадает по «роду» с payload’ом единственного unary-варианта C(Y) суммы W: литералу, переменной (в том числе связке образца match/if let/for), ro/mut без аннотации, инициализированной вызовом, чтению поля, вызову. Форма выражения значения не имеет; значение имеет только его тип. Правило действует во всех позициях, где действует D55: аргумент вызова, return, элемент литерала массива, поле литерала записи, ro/mut с аннотацией. Каждое принятое чекером выражение материализуется как W.C(expr) (см. «Реализация» ниже) — принятое и не обёрнутое выражение есть дефект компилятора, не свойство языка. Newtype-половина (п. 1) по-прежнему ограничена нетипизированными константами (амендмент 2026-08-21 выше).

type UserId int                              // newtype

ro id UserId = 100                            // 100 as UserId (было: E7301)
ro n = 100
ro id2 UserId = UserId(n)                     // переменная — только явно (амендмент 2026-08-21);
                                              // `ro id2 UserId = n` — E7301

Реализация: assignable/single_wrap_candidates/wrap_kind_of в compiler-codegen/src/types/mod.rs (accept-сторона, единое правило); материализация (AST-rewrite ${1} → SqlValue.Int(1)) — в уже существующем mutable-проходе annotate_map_literals/ MapLitAnnotator::try_wrap_leaf (тот же expected-type-propagated walker, что и map-литерал coercion — без отдельного нового прохода).

Генерики (амендмент, реестр 221.1 №320, окно p320, 2026-08-04): [M-generic-sumlift-mono-missing-variant-wrap] закрыт для варианта, чей payload — ИМЕНОВАННЫЙ тип, зависящий от generic-параметров expected (type Node[K, V] enum Empty | Leaf(Wrap[K, V]), Wrap[K, V] — своя value-декларация): w Wrap[K, V] в ro-return-позиции с ожидаемым Node[K, V] авто-оборачивается в Node.Leaf(w) — было ICE (return w; без обёртки → C-типовая несовместимость на границе функции) до Plan p320. До фикса single_wrap_candidates безусловно бейлилась на ЛЮБОЙ generic expected (гейт !generics.is_empty()); теперь Sum-плечо этот гейт не проверяет — WrapKind-дизамбигуация уже была name-only для Named-рода, так что собственные generics expected ей были не нужны. Материализация ТАКЖЕ сменила форму для generic-цели: голый Leaf(w) (как Some(x)/Ok(x) для Option/Result), а не квалифицированный Node.Leaf(w) (как для не-generic SqlValue.Int(1)) — emit_c.rs’s try_emit_explicit_variant_ctor намеренно отклоняет квалифицированный вызов на generic-сумме (её ctor дорога — mono-aware bare-Ident-путь).

НЕ закрыто (пример ниже — ИСТОРИЧЕСКИЙ, был добавлен как желаемое поведение и НЕ РАБОТАЛ уже на момент этого амендмента, независимо от Plan p320’s фикса выше): payload = ГОЛЫЙ generic-параметр сáмого sum’а (type Wrapper[T] enum W(T) | Empty, W(T) — T тут не именованный тип, а буквальное имя типового параметра). wrap_kind_of для такого payload’а даёт WrapKind::Named("T") (T не резолвится ни в один известный тип), что никогда не совпадёт с WrapKind::IntFamily/Str/etc. литерала/переменной без подстановки T → конкретный тип из expected.generics — эта подстановка НЕ реализована ни до, ни после Plan p320. ro w Wrapper[int] = 42 сегодня даёт [E7301] cannot assign value of type int to w declared as Wrapper[int]. Закрытие этого случая — отдельная, более инвазивная работа (генерик-aware WrapKind-подстановка в single_wrap_candidates/ wrap_kind_of), не начатая.

Str → ro []u8 coercion (D55 amend, Plan 208 Ф.0, 2026-07-15; правило подтверждено владельцем 2026-10-01)

Уточнено D488 (2026-10-01): размещение и передача значения — там единственный дом правила (место решает убегание, передачу ro — размер, порог три слова; mut — указатель). Где этот блок расходится с D488, действует D488.

Правило (решение владельца 2026-10-01): у str есть @bytes() с неявной коэрсией через #coerce, поэтому строка доступна везде, где нужен []u8. Механизм — D429: std объявляет пару #coerce export fn str @bytes() -> ro []u8 (std/src/runtime/string/core.nv, «view-lane pair str → ro []u8»); D55 задаёт позиции, D429 — механизм вставки. Отдельного правила «только литерал» нет и не было: литерал — частный случай str-значения. Поправка №492 ниже — не исключение, а само правило.

АМЕНДМЕНТ 2026-10-01 (решение владельца, №1480, вариант (а)): коэрсия — только в позиции только-для-чтения. «Везде, где нужен []u8» выше уточняется: везде, где нужен читающий []u8. Позиции коэрсии — те, где значение остаётся видом: параметр по умолчанию (x []u8, он ro), ro-связь с аннотацией (ro b []u8 = s), и любая позиция, чей тип написан ro []u8 — возврат -> ro []u8, элемент []ro []u8, поле записи f ro []u8. В позициях, где значение СОБСТВЕННОЕ и потом может стать изменяемым, — возврат -> []u8, элемент [][]u8, поле записи f []u8 — коэрсии НЕТ: там нужен явный s.bytes().clone(), без него — E_READONLY_COERCE на месте значения. Причина: fn f() -> []u8 => "abc"; mut b = f(); b[0] = 65 as u8 проходил проверку и падал SIGSEGV — вид строки утекал в собственный []u8 и отмывался обычной mut-связкой (пробы docs/plans/repro/d55-str-bytes/launder_*_segfault.nv.txt). Правило общее для всех view-пар D429 (I @m() -> ro O), не только для str: позиция, не названная выше, считается собственной (отказ по умолчанию). Ниже места прежнего текста, называвшие -> []u8 и [][]u8 позициями коэрсии, помечены этим амендментом, а не удалены.

В позиции с явным ожидаемым типом []u8 любое выражение типа str — литерал, переменная, результат вызова, чтение поля — принимается: компилятор АСТ-переписывает его в .bytes() (D429 R7), байт-в-байт как явный вызов, без обёртки и без копии:

fn Write mut @write(bytes []u8) -> ()
w.write("Point(")            // ✅ литерал → []u8 по паре #coerce str @bytes()
w.write("Point(" as []u8)    // эквивалент, явная форма тоже валидна

ro s = "Point("
w.write(s)                   // ✅ переменная — то же самое (D429; поправка №492)
w.write(s.bytes())           // ✅ явный .bytes() (D176) валиден, но избыточен: канон — голое значение (D429 R9)

Почему это допустимо. str — буфер {ptr,len} из UTF-8-байт (D139); @bytes() строит над ним вид без копии и без владения. Поэтому пара относится к «view»-полосе D429 (R2): zero-cost, без скрытой аллокации, и поэтому её цель — именно ro []u8, а не []u8-владелец. Коэрсия эквивалентна тому, как 100 принимается в позиции u8/UserId (case 4 / single-wrapper выше): пишущему не нужен явный жест, потому что ничего не копируется и ничего не передаётся во владение.

[]u8 и ro []u8. Коэрсия даёт ТОЛЬКО вид ro []u8 (буфер str иммутабелен). Поэтому она действует в позициях, где читающий []u8 — это read-only вид: параметр x []u8 (параметры ro по умолчанию, D176/D246 — ro писать нельзя, E_REDUNDANT_PARAM_RO), ro-связка с аннотацией []u8 (связка ro уже даёт ro-вид), возврат, элемент коллекции (амендмент 2026-10-01, №1480: только -> ro []u8 и []ro []u8; -> []u8 и [][]u8 — собственные позиции). В позиции, требующей ИЗМЕНЯЕМЫЙ []u8 (mut x []u8, consume), ro O не матчит (D429 R6): там нужен явный жест — s.bytes().clone() — иначе запись пошла бы в буфер str. То же — в СОБСТВЕННОЙ позиции (-> []u8, [][]u8, поле f []u8; амендмент №1480): её значение может стать изменяемым через mut-связку результата.

Позиции — таблица «явно ожидаемого типа» выше (case-таблица) и D429 R6: call-arg на резолвленный []u8-параметр (свободная функция, метод конкретного типа, метод через protocol-приёмник), ro с явной []u8-аннотацией, return-позиция (-> []u8 и -> ro []u8), элемент коллекции ([][]u8, []ro []u8), поле записи f ro []u8 (зачёркнутое снято амендментом 2026-10-01, №1480: собственные позиции, нужен s.bytes().clone()). Не ограничено @write — это ОБЩЕЕ правило для ЛЮБОЙ такой позиции (не отдельный @write-overload, отвергнутый в D422 §1: протокол Write остаётся чисто @write([]u8), без str-перегрузки).

ПОПРАВКА 2026-08-09 (реестр 221.1 №492) — теперь это и есть правило. Прежняя редакция ограничивала коэрсию литералом: «str-литерал (не переменная, не str-выражение)». Реализация этого ограничения НЕ имела — проверено прямой сборкой: take("hi") и ro s = "hi"; take(s) дают PASS: 1 FAIL: 0 одинаково. Расхождение стоило std лишнего метода: TcpStream.@write_str(s str), состоявший из Net.write(@, s.bytes()), был написан как обход ограничения, которого нет, и удалён вместе с этой поправкой (13 носителей переведены на .write(...)). Спека приведена к реализации: коэрсия для переменных удобна, безопасна (str уже держит байты, копии не возникает) и уже работала. 2026-10-01 владелец подтвердил это как правило; устаревшие места этого подраздела («w.write(s) — E_TYPE_MISMATCH», «Почему литерал, не любое str-значение», name-gated реализация) сняты и заменены текстом выше.

Статус реализации (проверено компилятором 2026-10-01 на главной ветке; nova check + nova build + запуск). Плоский «только метод write с литералом» (synthesize_write_str_lit_bytes_coercion, Plan 208 Ф.3) давно снесён; вставка идёт общим D429-проходом по значению. Фактически:

• Работает (литерал, переменная и результат вызова — check ✅, build ✅, запуск ✅): аргумент свободной функции с параметром []u8; метод конкретного типа (StringBuilder.write, BytesWriter.write); метод через protocol-приёмник (fn emit(mut w Write) — прежняя дыра «CC-FAIL на protocol-приёмнике» закрыта); элемент литерала [][]u8 и []ro []u8. Литерал и переменная — также в ro b []u8 = … и в возврате -> []u8 / -> ro []u8. Чтение поля и интерполяция "${s}" как аргумент — ✅.
• Не работает (расходится с правилом; правило остаётся, строки реестра заводит интегратор): (1) ro b []u8 = <вызов str> и = <чтение поля str> (также mut), а также return вызова или поля (-> []u8 => nm(), return rec.name) — check проходит, build падает в C (CC-FAIL: initializing/returning 'nova_str' … 'Nova_Vec____nova_byte *'); литерал и голый идентификатор в этих позициях работают; (2) scope-локальная const c []u8 = "…" — E_CONST_BYTES_NOT_CONSTEXPR на стадии codegen ([]u8 — куча, не constexpr; пишите ro); (3) str принимается в позиции mut []u8 (fn zap(mut b []u8), mut b []u8 = s) — check проходит, запись в такой буфер даёт SIGSEGV (литерал лежит в .rodata; для строки из кучи запись молча испортила бы str): это нарушает R2/R6 D429 (ro O не матчит mut-позицию) и оформлено как дефект, а не как часть правила. Пробы — docs/plans/repro/d55-str-bytes/.

АМЕНДМЕНТ СТАТУСА 2026-10-01 (после слияний №1451/№1452 и №1480). Абзац выше снят до №1452 и в двух пунктах устарел; текст оставлен как запись замера, верное сегодня — здесь:

• пункт (1) неверен: вызов, чтение поля, if/match-значение в ro-связке и в возврате больше не дают CC-FAIL — проверяющий записывает вердикт коэрсии по выражению, и переписывание вставляет .bytes() ровно туда, независимо от формы (одна дверь, compiler-codegen/src/types/coerce_door.rs, №1451);
• пункт (3) неверен: str в позиции mut []u8 (mut/consume-параметр, mut-связь, присваивание в неё) — E_READONLY_COERCE (№1452);
• собственные позиции (-> []u8, элемент [][]u8, поле f []u8) — E_READONLY_COERCE по амендменту №1480 выше; правило общее для всех view-пар, и позиция, которую ни одна ro-по-режиму позиция (параметр по умолчанию, ro-связь) не признала своей, считается собственной;
• протокольный приёмник: коэрсия аргумента закрыта (№1451/№1452: дверь применяется к аргументам по объявлению метода протокола), но сама сверка ТИПОВ аргументов с параметрами протокольного метода не делается — int проходит как []u8; это открытый №1481, не часть правила;
• пункт (2) (const c []u8 = "…" в области видимости) — без изменений. Фикстуры: spec_tests/conformance/standalone/p1452_str_bytes_positions.nv, standalone/p1480_str_bytes_owned_positions.nv, neg/p1452_str_bytes_mut_*_neg.nv, neg/p1480_*_neg.nv.

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]) — позже. АМЕНДМЕНТ 2026-08-30 (реестр №842): «позже» УЖЕ НАСТУПИЛО, и абзац описывал состояние до собственного расширения. Оракул читает АТРИБУТ, а не имя типа: compiler-codegen/src/ast/mod.rs:889 определяет #from_fields как маркер str-keyed map-типа ВООБЩЕ, а :2529 прямо обрабатывает случай «#from_fields type OTHER than HashMap». Значит любой пользовательский тип, объявивший #from_fields/#from_pairs и давший протокольные Self.new(cap), mut @cap(n) и mut @insert_new (см. пункт ниже), получает ту же коерсию — точка расширения открыта, отдельный FromFields[V] не понадобился. Абзац оставлен зачёркнутым, а не удалён: он объясняет, почему в коде рядом живут упоминания «bootstrap».

  Почему это важно читателю, а не только историку: пока строка стояла как действующая, она говорила «свой map-тип написать нельзя, ждите». Нашло окно 274 при подготовке волны коерсий — и нашло КОДОМ, а не аналогией, отдельно оговорив, что предыдущую свою находку (про HashMap без D-блока) оно само же отозвало как ложную аналогию.

• Протокол #from_fields: тип обязан иметь:

  • Self.new(cap int = …) -> Self — конструктор с ёмкостью параметром-умолчанием;
  • mut @cap(n int) -> () — сеттер ёмкости (предаллокация под n записей);
  • mut @insert_new(key str, val V) -> () — вставить новую запись (без возврата Option; дублей нет по construction). Отсутствие любого из методов → CC-FAIL при десугаринге.

  АМЕНДМЕНТ 2026-08-30 (реестр №844): здесь требовался static with_capacity(n int) -> Self — МЕТОД, СНЯТЫЙ АМЕНДМЕНТОМ D372 ОТ 2026-07-06. То есть тип, написанный ПО ЭТОЙ СПЕКЕ, реализовал бы несуществующий контракт и получил CC-FAIL на ровном месте. Сверено КОДОМ, четыре адреса: std/src/collections/hash_map/core.nv:173 («instance-method replacement for the removed HashMap[K, V].with_capacity»), :108 («sizing-helper для new() и сеттера mut @cap(n) (ex-with_capacity)»), :123 (живой конструктор export fn HashMap[K, V].new(cap int = 16)) и compiler-codegen/src/ast/mod.rs:893 — оракул требует дословно «ExpectedType.new() + .cap(n) + insert_new(k, v) per pair».

  Найдено окном 274 и владельцем; способ нахождения есть часть урока: окно скопировало эту строку в свой план КАК ФАКТ О РЕАЛИЗАЦИИ, не сверив с кодом. Правило отсюда: цитата из спеки, говорящая о том, ЧТО КОМПИЛЯТОР ТРЕБУЕТ, сверяется с компилятором, а не пересказывается.

Правила:

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 → F64(30.0); оба → JsonValue
   // (целый литерал 30 лёг бы в Int(30): у JsonValue с №1638 есть оба)
   

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

   { mut _m0 = HashMap[str, V].new(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 даёт похожее удобство более узким и контролируемым механизмом.

Уточнение 2026-10-01 (решение владельца; №1260). Авто-обёртка в вариант суммы (W.C(expr)) применяется к каждому выражению, которое чекер принимает по правилу D55, а не только к «голому» литералу или Ident: к литералу, переменной (включая связки образца match/if let/for), ro/mut без аннотации от вызова, чтению поля и вызову — во всех позициях D55 (аргумент, return, элемент литерала массива, поле литерала записи, ro/mut с аннотацией). Прежняя фраза «матчится только голый литерал/Ident, не Call/As» в §Obvious single-wrapper coercion описывала узость прежней материализации, а не правило, и снята; смысл абзаца про явный конструктор (значение уже типа W не оборачивается повторно) сохранён. Поведение компилятора — слияние №1260 (spec_tests/conformance/standalone/p1260_sumwrap_roundtrip.nv).

Уточнение 2026-10-01 (решение владельца): str → ro []u8 по #coerce, переменные включены. У str есть @bytes() с неявной коэрсией через #coerce (пара str @bytes() -> ro []u8, D429, std/src/runtime/string/core.nv), поэтому строка — литерал, переменная, результат вызова — доступна везде, где нужен []u8 (вид ro []u8, без копии и без владения). Поправка 2026-08-09 (реестр 221.1 №492) — это и есть правило; прежнее «только литерал», пример w.write(s) // ❌ E_TYPE_MISMATCH, абзац «Почему литерал, не любое str-значение» и «Статус реализации (Plan 208 Ф.3)» в подразделе «Str → ro []u8 coercion» сняты. В позицию изменяемого mut []u8 коэрсия не идёт (D429 R6); амендмент 2026-10-01 (№1480, вариант (а)): не идёт и в собственную позицию — -> []u8, элемент [][]u8, поле f []u8 (нужен s.bytes().clone(); вид — в -> ro []u8, []ro []u8, f ro []u8). Что из позиций сегодня реально работает, а что расходится с правилом — там же, «Статус реализации».

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
    @equal(other Self) -> bool
}

type Iterator[T] protocol {
    mut @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 {
    mut @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 {
    mut @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 — открытый вопрос.

D443. use — hard keyword → контекстный keyword (Plan 239, 2026-08-01)

Что

use retracted из hard keyword (TokenKind::KwUse, безусловный, как let/ const) в контекстный keyword — тем же механизмом, что bench/measure (D121) и apply/null (D278 §3): лексер выдаёт Ident("use") всегда, парсер распознаёт use позиционно в трёх местах, где у него уже была синтаксическая роль:

1. import-synonym — use path.to.mod (alias import, с bootstrap).
2. record-field embed (D39) — use alias Type внутри type { ... }.
3. protocol embed (D145 §Protocol composition) — use TypeName в начале protocol { ... } тела.

Вне этих трёх позиций use — обычный идентификатор: имя поля, переменной, функции, параметра, namespace-сегмента.

Правило

Disambiguation — lookahead на 1-2 токена вперёд от Ident("use"), зеркало bench-техники (D121 «parses как item только когда за bench идёт string-literal»):

• Top-level item position: Ident("use") + следующий токен Ident/./ .. (похоже на начало dotted-path или relative-anchor) ⇒ import-synonym. Иначе use не участвует в top-level item dispatch (падает в generic «expected fn/type/…» путь, как любой другой стрей-идентификатор на этой позиции).
• Record-field list (внутри type { ... }): Ident("use") + Ident (alias или _) + токен ПОСЛЕ него НЕ разделитель полей (,/newline/;/ }) ⇒ embed (use alias Type/use _ Type). Иначе — обычное поле с именем use (use SomeType — 1 идентификатор перед типом, как у любого другого поля). Единственный известный remaining edge-case: поле use с generic- типом (use Vec[T]) синтаксически неотличимо от use Vec [T]-подобного embed по этому 2-токенному lookahead — задокументировано как компромисс (Plan 239 §2), не заблокировано отдельным механизмом (тот же класс trade-off, что у bench/apply).
• Protocol body leading items: Ident("use") + Ident (имя типа) ⇒ embed. use( (метод по имени use, bare-ident effect-syntax) НЕ embed — проваливается в обычный method-parse путь. Раньше (hard keyword) метод с именем use был НЕВОЗМОЖЕН даже bare-ident’ом в effect-теле — теперь разрешено.

Почему

Будучи hard keyword, use был единственным из этой группы контекстных слов, полностью недоступным как идентификатор — при том что у bench/ measure/apply/null (D121, D278 §3) ровно такая многопозиционная семантика уже жила как Ident с parser-side disambiguation. Асимметрия не имела отдельного обоснования: все три существующие роли use синтаксически однозначно определяются позицией + 1-2 токенами lookahead, без коллизий с уже написанным кодом ( grep std/examples на \buse\b: 100% вхождений — use TypeName-embeds, комментарии/строки; ни одного идентификатора use не найдено — retraction расширяет допустимые программы, не сужает).

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

• Оставить hard keyword — статус-кво до этого плана; отклонено по просьбе владельца (симметрия с bench).
• Диагностика E_RESERVED_WORD при misuse (запасной вариант из брифа на случай «резерв без формы невозможен») — не понадобилась: у use, в отличие от гипотетического «зарезервировать под будущее», уже есть три РЕАЛЬНЫЕ синтаксические формы; misuse просто не парсится как use-форма и проваливается в generic diagnostic соответствующей позиции (тот же silent-fallthrough, что у bench).
• Подсветка use в редакторах наравне с bench (буквальная формулировка исходного брифа: «добавить use рядом с bench» в tmLanguage) — ПРОТИВОПОЛОЖНО верному направлению. D278 §3 нормативно требует ОБРАТНОГО: контекстные keyword’ы (apply/bench/measure/null, теперь +use) намеренно НЕ подсвечиваются — лексер держит их идентификаторами во избежание поломки пользовательских имён, и живой conformance-тест (compiler-codegen/tests/syntax_highlight_conformance.rs, vscode_grammar_has_no_phantom_keywords и парные vim/zed) фейлится, если контекстное слово остаётся в keyword-паттерне хайлайтера. use снят из editors/vscode/syntaxes/nova.tmLanguage.json, editors/vim/syntax/nova.vim, editors/zed/languages/nova/highlights.scm этим планом — брифовая формулировка была основана на неверной посылке «use пока не зарезервирован» (на деле был hard keyword).

Связь

• D39 — record-field embed; семантика embed НЕ меняется, меняется только классификация токена.
• D145 §Protocol composition — protocol embed; аналогично, без изменений семантики.
• D121 — прецедент техники (bench/measure contextual lexing).
• D278 — §3 governance-правило «контекстные keyword’ы не подсвечиваются»; use добавлен в перечень.
• Q-embed-syntax — вопрос выбора keyword’а (use vs embed) остаётся ОТКРЫТ; эта retraction снимает один аргумент «за» пересмотр (use больше не занимает identifier- пространство целиком), но не разрешает многопозиционную перегрузку семантики самого слова.
• Plan 239 — план окна, полный список затронутых файлов.

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

Уточнено D488 (2026-10-01): размещение и передача значения — там единственный дом правила (место решает убегание, передачу ro — размер, порог три слова; mut — указатель). Где этот блок расходится с D488, действует D488.

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

AMEND (2026-09-25, D32; форма — интегратор, текст — окно Карины): строка «Sum types» приведена к D477. Она стояла как type X | A | B / «managed heap» / «by reference» / Nova_<X>* — протухла дважды: синтаксис объявления суммы — type X enum A | B, а размещение — ПО ЗНАЧЕНИЮ, рекурсия разрывается маркером indirect на варианте (D477, решение владельца 2026-09-13; подтверждено владельцем 2026-09-25). Следствие, ради которого правка понадобилась: сумма — value-тип, и == на ней идёт через Equal по заявке #impl(Equal) БЕЗ identity-фоллбэка — правило value-типов (08-runtime.md, «Value-record / NamedTuple … #impl(P) opt-in»), а не heap-record. Оракул сегодня пропускает == без заявки — реестр 221.1 №1352. Колонка mut-ABI для суммы здесь не нормирована: прежнее Nova_<X>* описывало кучу.

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’а, ro для never-mut, mut per-field — только для cache/lazy. Семантика параметров не менялась.

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

Уточнено D35 (2026-10-02, №1636): вызов мутирующего метода на цепочке полей приёмника @ без mut — отказ, как на ro-привязке; стена — поле *mut (D175 §V2).

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

Что

Поле без префикса мутируется, если binding mutable. ro запрещает мутацию даже у mutable binding’а (для id, foreign keys, invariants). mut per-field разрешает мутацию даже у immutable binding’а (для cache, lazy init, atomic counters — аналог C++ mutable). Снято амендментом D175 «binding dominates» (Plan 124.8 Ф.3; см. таблицу там): mut-поле через ro-привязку, параметр без mut и приёмник @ без mut НЕ мутируется — E_READONLY_FIELD (для @ — D35 амендмент 2026-10-02, реестр №1635). Пример LazyConfig ниже пишется с fn LazyConfig mut @get(). 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'ами — ro для 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 mut @get() -> str {   // `mut @` — D175 binding dominates, D35 амендмент 2026-10-02
    if Some(v) = @cached_value { return v }
    ro v = read_file(@path)
    @cached_value = Some(v)         // мутация только через `mut @`
    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. Сигнатура показывает только важное. Префикс ставится только на исключения (ro для invariants, mut для cache). LLM, читая тип, видит: ro id — «не трогай», обычное поле — «можно мутировать с mut-binding’ом».
3. Прецедент Rust/Go/C++ — поля без префикса мутируются у mut-binding’а; ro для 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). ro прямо говорит «только для чтения».
• let для never-mut полей. Короче (3 символа), прецедент Swift, но let уже значит «binding имени со значением» (03-syntax.md → D33). На поле без = необычно, не самообъясняемо. ro прямо говорит цель.
• 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; на поле — аналогия в роли ro.
• 03-syntax.md → D35 — fn Type mut @method даёт mutable-binding self, поля затем по правилам D36.

Эволюция

До D36 поле помечалось mut field T, мутируемое только у mut-binding’а (D32). Для аккумуляторов это требовало 18 раз повторить mut — шум без пользы. D36 инвертировал дефолт: «обычное поле — мутируется у mut-binding’а», ro — для исключений. Семантика параметров (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 — ro field полный freeze.
• 02-types.md → D176 — ro 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)

Уточнено D35 (2026-10-02, №1636): транзитивность и для приёмника @ без mut: @tags.items.push(x) — отказ; цепочка через поле *mut законна (§V2 «L2 wall-at-*»).

📌 Полная модель мутабельности — 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 — тип-модификатор

Уточнено D35 (2026-10-02, №1636): приёмник @ без mut — параметр: mut-метод на цепочке его полей — E_PARAM_NOT_MUT; через поле *mut — законно (D175 §V2).

Уточнено D488 (2026-10-01): размещение и передача значения — там единственный дом правила (место решает убегание, передачу ro — размер, порог три слова; mut — указатель). Где этот блок расходится с D488, действует D488.

📌 Полная модель мутабельности — 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, -> consume T, -> *mut T, -> *ro T) — берётся как написан (для указателей модификатор всегда относится к pointee — postfix; prefix перед * = E_POINTER_PREFIX_MODIFIER, D216 §1). -> consume T — префиксная форма, симметричная -> ro T/-> mut T

⚠️ ПЕРЕКРЫТО D445 §616 (пометка 2026-08-17 по аудиту самосогласованности). Форма -> consume T в позиции ВОЗВРАТА снята ЦЕЛИКОМ — «не переопределена, а удалена»: E_RETURN_CONSUME_PREFIX_RETRACTED для префиксной и E_RETURN_CONSUME_POSTFIX_RETRACTED для постфиксной (№301). Пять носителей в std/src/runtime/sync.nv переписаны на голый -> MutexGuard тем же слиянием. Класс держится стражем check-retracted-param-form (храповик осадка по зонам). Текст выше сохранён как история. (D445, №301/221.1, окно p-lang, 2026-08-04); старая постфиксная -> T consume (Plan 103.9) РЕТРАКТИРОВАНА.

• -> Self (статический Self-тип, D182) — owned-by-caller; не наследует receiver-мут.
• -> @ без receiver-method context (free fn) → E_AT_RETURN_OUTSIDE_METHOD.

Escape hatch

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

Рантайм

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

Применение

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

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

Default = read-only. Параметр без явного модификатора эквивалентен ro 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 в позиции параметра уже ro по умолчанию. Поэтому ro T → T (param) — это ro → ro (тождество), а единственное реальное нарушение это ro → 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 уже ro, поэтому coerce ro T → T (param) — это ro → ro (no violation). Единственный остаточный case — ro T → mut T (param explicit) — отдельный followup [M-108.1-readonly-to-explicit-mut-coerce] (узкий нишевый сценарий, не блокирует).

Связь

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

D445. Модификатор ВСЕГДА перед тем, что описывает (ro/mut/consume) {#d445}

Статус: ✅ IMPLEMENTED. Решение владельца, 2026-08-03 (реестр 221.1 №301); реализовано окном p-lang, 2026-08-04.

AMEND (2026-08-12, owner decision, реестр 221.1 №616/№611/№615, окно p616-mode-modifiers). Три формы, у которых была ЗАПИСЬ, но не было ПРАВИЛА за ней, — сняты без периода deprecated:

1. -> consume T (позиция возврата) снят ЦЕЛИКОМ — не переопределён, а ОТМЕНЁН. Пробой (docs/plans/wip/repro-616-consume-return.nv.txt) доказано: модификатор не добавляет семантики. Тип, объявленный consume, держит линейность САМ ПО СЕБЕ — ro g = make_guard() для fn make_guard() -> Guard (без -> consume на функции) уже даёт E_CONSUME_KEYWORD_MISSING (D180). А тип, НЕ объявленный consume, возвращённый как -> consume Box, компилируется и пропускает ro b = make_box() БЕЗ потребления — модификатор в этом случае ОБЕЩАЕТ линейность, которой у типа нет. Ни в одном из двух случаев модификатор не делает ничего полезного, во втором — вредит (ложное обещание). Обе строки таблицы ниже (-> consume T и пример-код) — удалены; return-позиция для consume больше не существует НИ В КАКОЙ форме — E_RETURN_CONSUME_PREFIX_RETRACTED (новая, эта форма) рядом с уже существовавшей E_RETURN_CONSUME_POSTFIX_RETRACTED (постфикс, №301). Пять носителей в std/src/runtime/sync.nv (Mutex@lock, RwLock@read/@write, Once@make_guard, Semaphore@acquire) — переписаны на голый -> MutexGuard и родню в том же слиянии.
2. Постфикс имя mut Тип в параметре — исключение отменяется по имени. Амендмент 2026-07-17 к D374 (AMEND ×3, канон mut-параметров) объявил голую постфиксную форму ЗАПРЕЩЁННОЙ лint’ом (W_PARAM_TYPE_POS_MUT), но оставил ЖИВОЕ исключение «легитимна ИСКЛЮЧИТЕЛЬНО за view-слайсами ([]u8) и fixed-size массивами ([N]u8)» — именно то исключение, которое этот D-блок отменял ПО СМЫСЛУ («без исключений и без постфиксной формы где бы то ни было»), но не назвал по имени, из-за чего исключение и дожило почти на девять дней. Теперь названо и закрыто: исключение для view-слайсов/fixed-массивов снято, W_PARAM_TYPE_POS_MUT (лайт, лишь предупреждал) заменён на жёсткую ошибку E_PARAM_TYPE_POS_MUT_RETRACTED. Канон параметра — РОВНО три формы: buf Type / mut buf Type / consume buf Type.
3. R2-split ro имя mut Тип в параметре — санкционированность снята. Тот же амендмент 2026-07-17 называл ro name mut Type «санкционированным, не каноническим, исключением», которое «самодокументирует „пишу в содержимое, не подменяю биндинг“» (ссылки на D246 P6, Plan 118.5 V3 amend). Проба показала: запись через такой параметр даёт E_READONLY_CONTENT — форма, придуманная для записи в содержимое, саму запись и запрещает. Санкционированность снята вместе с постфиксом из пункта 2 (та же синтаксическая форма, просто с явным ro спереди); spec_tests/conformance/d246_param_ro_mut_view.nv (позитивный дискриминатор, доказывавший легальность формы) удалён — его роль теперь играет негативная фикстура spec_tests/conformance/neg/param_type_pos_mut_r2_split_retracted_neg.nv. Не путать с R2-split ЛОКАЛЬНОГО биндинга (ro r mut Point — ЛОКАЛЬНАЯ переменная, не параметр, D246 §«R1 vs R2», ro a mut T в таблице мутабельности) — тот механизм НЕ затронут, живёт своей жизнью на другой оси (L1×L2 локального биндинга, а не позиция параметра).

Новый D-блок не заводится — амендмент правит существующий D445.

Что

Единое правило размещения для всех трёх модификаторов режима (ro/mut/ consume) во ВСЕХ позициях грамматики: модификатор всегда стоит перед тем, что он описывает, без исключений и без постфиксной формы где бы то ни было.

// Возврат: ro/mut — по-прежнему ПЕРЕД типом. `consume` в этой позиции
// СНЯТ (AMEND 2026-08-12, №616) — линейность несёт объявление типа
// (`type MutexGuard consume { … }`, D180), не return-аннотация.
fn Mutex @lock() -> MutexGuard
fn RwLock @read() -> ReadGuard
fn RwLock @write() -> WriteGuard

Зачем

До 2026-08-03 была асимметрия. ro/mut в позиции возврата писались ПЕРЕД типом (-> ro Self, -> ro []u8 — так уже было в std), а consume (Plan 103.9) — ПОСЛЕ (-> MutexGuard consume, 5 мест в std/src/runtime/sync.nv: Mutex@lock, RwLock@read/@write, Once@make_guard, Semaphore@acquire). В позиции возврата все три модификатора отвечают на один и тот же вопрос («что можно делать с полученным значением»), но стояли по разные стороны типа — единственный постфикс во всей грамматике модификаторов.

Постфикс ретрактирован, не переопределён. Ранняя формулировка этого правила («единственный постфикс — на объявлении типа», зафиксированная в черновике решения владельца 2026-08-03) была ошибочной и в этот D-блок не входит: type X consume { … } — это НЕ постфикс на имени типа X, а модификатор ПЕРЕД телом { … } — тем же слотом, который занимают value (type X value { … }) и enum (type X enum A | B). Модификатор здесь тоже стоит перед тем, что описывает (тело типа), просто «то, что описывает» идёт не сразу за именем типа. Постфиксной позиции для модификатора режима не существует нигде в грамматике.

Как

Текущее состояние (после AMEND 2026-08-12, №616). Парсер: return-позиция (-> …) видит consume СРАЗУ после -> — E_RETURN_CONSUME_PREFIX_RETRACTED (hard error, fix-it: убрать consume, -> T). consume СРАЗУ после типа возврата (старый постфикс, №301) — E_RETURN_CONSUME_POSTFIX_RETRACTED, тот же fix-it. Обе формы — parser/mod.rs, ветка после ->, ДО и ПОСЛЕ parse_type() соответственно. Параметр: постфикс имя mut Тип (голый И ro имя mut Тип) — E_PARAM_TYPE_POS_MUT_RETRACTED (parser/mod.rs parse_param, ветка после parse_ident), без исключений по типу (view-слайсы и fixed-массивы включены). Лint W_PARAM_TYPE_POS_MUT (lints.rs) снят вместе с формой, которую он предупреждал, а не запрещал.

Связь

• D176 — -> ro T/-> mut T в позиции возврата (симметрия с consume, пока последний не сняли целиком, №616)
• D133 — consume-семантика типа/значения (несёт линейность и БЕЗ модификатора в return-позиции, №616)
• D156 — [T consume] generic bound (комбинация с протокольной цепочкой — см. правку раздела «Синтаксис bound» выше, №300/221.1)
• 10-overloading.md D84 — режим {ro,mut,consume} как ось перегрузки (диспатч по форме привязки уточнён тем же окном — №309/221.1)
• D374 AMEND ×3 (2026-07-17) — канон mut-параметров, чей carve-out для view-слайсов/fixed-массивов и R2-split этот амендмент отменяет (№611/№615)
• D246 — три оси мутабельности; R2-split ЛОКАЛЬНОГО биндинга (не параметра) этим амендментом не затронут

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
    @equal(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, СТАТИЧЕСКИЙ — точка, не `@` (D209)
}

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 SignedInts]). Тот же 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 не нужно держать «отложенный контекст»).

⚠️ D72 §«Порядок объявления параметров» — ПРАВИЛО СНЯТО (решение владельца 2026-08-16; реестр №702). Имена одного generic-списка видны друг другу ЦЕЛИКОМ: fn f[T From[K], K](v K) -> T — законно, как и fn f[K, T From[K]]. Прецедент — rustc (fn f<T: From<K>, K> законно). Основание снятия — три факта, а не вкус: (1) правило никогда не действовало — чекер порядок не проверял (check_generic_bound_declarations, types/mod.rs:26054, валидирует только имена бáундов); (2) std САМ пишет forward-order и компилируется (std/src/testing/property.nv:224,304 — [G Generator[T], T]); (3) D145 §«Bound syntax (через D72)» даёт эту форму как валидный пример. Собственное обоснование правила — «ради простоты type-checker’а» — истекло: чекер справляется без него. Снятие не меняет ни одной компилирующейся программы; реализация правила сломала бы std и D145. Что НЕ затронуто: D88 (forward-ref в ДЕФОЛТАХ [T = X]) остаётся запретом — там порядок нужен для вычисления значения, здесь — нет. Пример-ошибка выше сохранён как ИСТОРИЯ и более не нормативен.

Bound — это protocol-тип

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

type Hash protocol {
    @hash() -> u64
    @equal(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 — ЗАКРЫТО планом 101.3 (ред. 5, 2026-05-25): форма композиции — +, [T Hash + Equal]. Реализовано и проверено пробой 2026-08-03. Кандидаты & и (Hash, Eq) из прежней редакции ОТКЛОНЕНЫ; запись оставалась в «открытых вопросах» по недосмотру (№299).
• 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(mut xs []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

Уточнено D488 (2026-10-01): размещение и передача значения — там единственный дом правила (место решает убегание, передачу ro — размер, порог три слова; mut — указатель). Где этот блок расходится с D488, действует D488.

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 — ПОЗИЦИОННО (амендмент 2026-08-05; прежние примеры показывали
// именованные аргументы для полей БЕЗ дефолтов, что противоречит D102).
// ЦИТАТА ПОЧИНЕНА 2026-09-04: здесь стояло «см. ниже "Конструирование и
// деструктуризация"» — раздела с таким именем в spec/ НЕТ НИ ОДНОГО (проверено
// грепом окном 274), то есть правило два месяца опиралось на несуществующий
// адрес. Настоящие адреса: конструирование — D102 (03-syntax.md, редакция
// 2026-09-04: обязательный позиционно, дефолтный по имени); разбор на части —
// D411 (03-syntax.md): фигурная форма для именованных полей, круглая для
// позиционных. Заодно исчезла и причина спора: на день амендмента D102 говорил
// обратное тому, на что амендмент ссылался, и был приведён в соответствие
// решением владельца 2026-09-04.
ro v = Vec3(1.0, 2.0, 3.0)
ro c = Color(255, 0, 128, 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 + other.x, @y + other.y, @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/dev/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/guards/lint-no-silent-int-fallback.sh greps compiler-codegen/src/ против baseline counts из docs/dev/codegen-erasure-sites.md. Bumping baseline требует:

1. Inline comment с rationale «почему erasure безопасна»
2. Entry в docs/dev/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/guards/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/dev/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 (существующее поведение сохранено).

АМЕНДМЕНТ 2026-09-04 (решение владельца; исследование docs/dev/research/2026-09-04-numeric-widening.md §5, реестр №928, проба docs/plans/repro/928-as-int-uint-saturation/). Две правки к этому блоку.

1. uint — РАЗНЫЙ тип с u64, как int с i64 (D129, AMEND Plan 133). Слово «alias» в заголовке и в Q1 — историческое, из эпохи до Plan 133: uint → nova_uint (uintptr_t, address-sized), u64 → uint64_t (всегда 64 бита); на bootstrap они совпадают по ширине, но это РАЗНЫЕ типы с разными mangle-именами (NovaOpt_nova_uint ≠ NovaOpt_uint64_t), как Go uint ≠ uint64, Rust usize ≠ u64. Следствие для D405: «одинаковый конкретный числовой тип» значит одинаковый ПО ИМЕНИ — int + i64, uint + u64, ro e u64 = c при c uint — ошибки, явный as. Сегодня чекер сравнивает ширины и пропускает всё это (строка реестра «чекер считает int ≡ i64»); это дефект по букве D129.

2. Q2 СНЯТ: int as uint — bit-pattern, как всякий iN → uM (таблица D54). Q2 вводил насыщение для одной пары (-1 as uint → 0), тогда как -1 as u64, (-5 as i32) as uint и все прочие знаковые→беззнаковые — bit-pattern: одна операция, три ответа (№928). Довод Plan 70.5 Q2 («Rust bit-cast hostile») был общим, норма — частной; владелец выбрал единую таблицу D54: as — «я явно попросил переинтерпретацию», для отсечения есть имена (@to_uint() D430, max(0, x) as uint), для битов имени, кроме as, нет; доноры Rust/Go/Java. Helper nova_int_to_uint и acceptance-строка «int as uint saturates» — ретрагированы; насыщение остаётся только у float → int (донор Rust 1.45). Страницы conversions.* («между целочисленными ширинами всегда wraparound») были правы.

Дизайн (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 СНЯТО 2026-09-04 (амендмент выше)
• 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). СМ. ТАКЖЕ D432 и его амендмент rev-2 (2026-09-16): у типа с эффект-free @cleanup линейность смягчается до аффинной НЕ ТОЛЬКО для формы consume X = e, но и для consume-ПАРАМЕТРА. 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

Амендмент 2026-09-14 (реестр 221.1 №1092, решение владельца): строка «(a, b) в позиции возврата» — НОРМАТИВНОЕ дополнение перечня. До неё перечень покрывал return tx и конструирование record-литерала (T { field: tx, … }), но НЕ кортеж, и потому fn f(consume a T, consume b T) -> (T, T) => (a, b) отвергалась как «не consumed до scope-exit» — при том что тело функции ЕСТЬ весь её результат.

Почему это дополнение, а не смена решения. Кортеж — такое же конструирование, как record-литерал, только без имён полей; строка про record-литерал в перечне стоит с 2026-07-13 и называет это «move при конструировании». Перечень был неполон по недосмотру, а не по решению: ни одного места, где кортеж в позиции возврата объявлялся бы НЕ потреблением, в спеке нет.

Цена умолчания измерена. Обход стоял в std/src/net/tcp.nv:113 (split_pair) с 2026-07: параметры оставлены view-формой, а результат помечен ro, и собственный комментарий признавал компромисс словами «ro would be the wrong canon here» с меткой [INV-PROPERTY]. Второй носитель той же формы — std/src/net/udp.nv:40 (recv_bytes_pair). Обе функции отдают владение и обе были вынуждены лгать о нём в подписи.

Санкция: владелец 2026-09-14, прочитав подписи split_pair и @into_split() рядом, утвердил форму fn split_pair(consume rh TcpReadHalf, consume wh TcpWriteHalf) -> (TcpReadHalf, TcpWriteHalf). Это правило — то, без чего утверждённая форма не компилируется.

Амендмент 2026-07-13 (fix [M-178-consume-field-ctor-from-var]): строка «init consume-поля record-литерала» — НОРМАТИВНОЕ уточнение, закрывающее языковой обход. Инициализация consume-поля record-литерала голой owned-переменной или consume-параметром ({ tcp: stream, session }) — потребление этого биндинга, ровно как передача в consume-параметр вызова. Действует для всех форм литерала: типизированного (T { … } / record-вариант суммы V { … }), анонимного с типом из контекста (=> { tcp: stream, session } — best-effort структурный резолв; неоднозначность → консервативно без move, остаётся D133-not-consumed) и D52-punning ({ tx }). Использование биндинга ПОСЛЕ литерала — use-after-consume (D131); два consume-поля из одного биндинга — то же. До амендмента распознавалось только свежее inline-выражение/вызов в позиции поля, что вынуждало pass-through-обёртки вида fn tcp_move(consume s TcpStream) -> TcpStream => s.

Заразность через поля + 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-метод. Смягчено D432 (Plan 217, 2026-07-20): аргумент «размывает выбор» относился к безусловному drop БЕЗ доступа к исходу. После введения ScopeOutcome (D314) авто-@cleanup(outcome) ветвится по исходу (Success/Failure(e)/Panic(m)) так же явно, как ручной вызов в consume X = e { body } (D188) — размывания больше нет. D432 разрешает авто-вызов КАК OPT-IN: только для типов, объявивших эффект-чистый @cleanup (§8а п.1 плана 217). Тип БЕЗ @cleanup (например StringBuilder — потребление извлекает ценность, тихий drop = потеря работы) остаётся строго-линейным без изменений — «явный 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.
• D432 Plan 217 — авто-@cleanup (гибрид C): смягчает «Что отвергнуто»/Drop-method пункт выше для эффект-чистых @cleanup-типов; оставляет строгую линейность (эта секция, без изменений) для типов без @cleanup.

D432. Авто-@cleanup для непотреблённых consume-переменных (гибрид C) {#d432}

Статус: ПРИНЯТО (Plan 217, владелец 2026-07-20, решения §8а). Амендирует: D133 §«Что отвергнуто» (Drop-method auto-cleanup, смягчено выше), D131/D180 Rule 6 (не применяется к @cleanup-типам, см. ниже), D314 (переиспользует defer-kernel как транспорт, §3 ниже).

Суть (гибрид C)

Для type X consume, объявившего @cleanup, — семантика сдвигается с линейной (=1, D133 «ровно один раз») на аффинную (≤1, D131-стиль «забыть можно»): непотребление к концу скоупа БОЛЬШЕ НЕ ошибка, компилятор сам вставляет вызов @cleanup(outcome) на висячих exit-путях. Для type X consume БЕЗ @cleanup — D133 действует без изменений (строгая линейность, явное потребление обязательно).

Выбор аффинный/линейный делается САМИМ фактом объявления @cleanup — видимый в исходнике признак, без скрытой магии и без нового keyword’а. Канонический пример линейного класса — StringBuilder (@into_str извлекает ценность; тихий авто-drop потерял бы построенную строку) — такие типы @cleanup НЕ объявляют и остаются строго-линейными.

§1. Ограждение 1 — эффект-чистота (ГЛАВНОЕ, обязательное)

Авто-cleanup применяется ТОЛЬКО к типам, чей @cleanup(outcome ScopeOutcome) -> () объявлен с ПУСТЫМ effect-row (эквивалент Cleanup[never]). Прецедент 214 R12 (эффект-свобода — E_COERCE_EFFECTFUL): скрытый эффект в неявной позиции запрещён под --strict-effects. Fallible-@cleanup (непустой effect-row, например Fail[IoError]) остаётся строго-линейным — D133 диагностика (D133-not-consumed) продолжает срабатывать для него БЕЗ ИЗМЕНЕНИЙ, как если бы D432 не существовал. Включение fallible-cleanup (эффект-пропагация в сигнатуру объемлющей функции ИЛИ иная политика) — отдельное будущее решение, вне периметра D432.

АМЕНДМЕНТ 2026-08-04 (решение владельца) — дверь, оставленная выше, открыта: эффектная и падающая очистка РАЗРЕШЕНА с пропагацией.

Ограничение «только пустой effect-row» снимается. Правило:

1. Эффекты авто-вставленного вызова @cleanup — ПРЯМЫЕ эффекты объемлющей функции. Не транзитивные: вызов физически генерируется в теле ЭТОЙ функции, значит эффект происходит здесь. Различие существенно — по D62 транзитивные эффекты дают лишь предупреждение, и без этой фразы правило выродилось бы в необязательное.
2. Fail[E] очистки обязан появиться в сигнатуре объемлющей функции. Формулировка владельца 2026-08-04: «эффект Fail должен появиться в функции, если его требует процесс авто-очистки». Новым правилом это НЕ является — действующая норма уже говорит ровно это: Fail есть исключение из «только прямые», он строго транзитивен и обязателен в сигнатуре везде, где может произойти, и не ослабляется никаким флагом (обзор spec/effects.ru.md, раздел «Прямые эффекты, не транзитивные»; D65). Отсюда важный вывод для планирования: №315 — не языковой пробел, а дефект реализации. Проверка не видит синтезированный вызов очистки, потому что десугаринг блочной формы идёт ПОСЛЕ проверок эффектов. Правило менять не нужно, нужно чинить чекер.
3. Кто пишет — по D28/D62, без новой политики: в private-функции компилятор выводит и добавляет сам; в export fn прямые эффекты обязательны явно, поэтому отсутствие Fail[E]/Fs — ошибка компиляции с указанием на биндинг, который её породил.
4. Отказ очистки на уже падающем пути ПРИСОЕДИНЯЕТСЯ, а не замещает. Решается по outcome, который в очистку уже передаётся: при Success отказ очистки распространяется как отказ функции; при Failure/Panic — присоединяется к исходной причине. Модель подавленных исключений Java. Альтернатива «замещать» теряет первопричину, а «молча глотать» — путь Go с defer f.Close(), где ошибка закрытия исчезает; оба отвергнуты.

Следствие: File и TcpStream перестают быть исключением из авто-очистки (см. std/src/fs/fs.nv:181 — комментарий об исключении подлежит снятию тем же слиянием, что и реализация). Контейнеров это НЕ касается — см. §2 ниже: drop-glue не вводится, и Vec[File] по-прежнему не прибирается поэлементно. Для контейнеров действует наследование линейности (амендмент к D156), а не авто-очистка.

§2. Ограждение 3 — НЕ рекурсивен (нет drop-glue)

Авто-cleanup применяется ТОЛЬКО к именованным bare consume-биндингам (consume X = e;, одиночный Ident-паттерн). НЕТ drop-glue: record с @cleanup-полем, Vec[TlsStream] и прочие агрегаты/контейнеры полем/ поэлементно НЕ прибираются — правила передач владения (Stored-in- escaping-field = Transferred, D131) не меняются. Деструктурирующие паттерны (let (a, b) = e, let { x, y } = e) — НЕ покрываются (остаются под старым D133, если применимо).

Амендмент 2026-08-15 (реестр 221.1 №667): «паттерн» здесь — ЛЮБОЙ паттерн, включая арм match и if let. Формулировка выше перечисляла только let (a, b) / let { x, y }, и это прочли как «про кортежи и записи», а не как правило. Биндинг, введённый ПАТТЕРНОМ — match e { Ok(consume r) => … }, if let Ok(consume r) = e { … } — авто-cleanup НЕ получает: кодоген армит DeferEntry только для bare-Stmt::Let с одиночным Ident (auto_cleanup_qualifies(&LetDecl)), у паттерн-биндинга точки постановки нет вовсе. Значит непотребление такого биндинга — честная ошибка D133-not-consumed, а не тихое принятие: чекер обязан снимать D432-исключение ровно там, где кодоген ничего не вставляет. Что это стоило до амендмента: nova-polaris брал слот семафора арм-биндингом (Some(consume p) => …) с комментарием «D432 вернёт слот на выходе» — слот не возвращался никогда, и после max_inflight соединений сервер вставал молча. Норму держат фикстуры spec_tests/conformance/neg/m667_arm_binding_leak_neg.nv (утечка = ошибка) и standalone/m667_arm_binding_and_variant_ctor_ownership.nv (все законные маршруты владения компилируются).