Syntax — синтаксис, литералы, операторы, методы

Решения этой группы фиксируют поверхностный синтаксис Nova: формы объявлений, стрелки, литералы, методы, операторы. Семантика типов и эффектов — в 02-types.md и 04-effects.md; здесь — только запись.

D16. Дженерики через [T], не <T>

Что

Параметры типа записываются в квадратных скобках, не угловых.

Правило

fn sort[T](xs []T, less fn(T, T) -> bool) -> []T
type Option[T] | Some(T) | None
type HashMap[K, V] { ... }

ro parsed = parse[int]("42")?

[T] — это generic-применение к именованному типу или функции (Имя[T]). Само по себе [T] массивом не является — для массивов есть []T (D27).

Грамматика однозначна:

• Имя[T] после идентификатора — generic-применение.
• []T, [N]T без имени слева — конструкция массива.
• arr[i] в позиции выражения — индексация.

Почему

1. Парсер однозначен — после имени [ всегда генерик; <T> создаёт известную ambiguity (sort<int>(xs) — генерик или сравнение?).
2. Турбофиш не нужен — parse[int]("42") работает напрямую (D38).
3. Скорость компиляции — нет backtracking, важно для AI-first, где LLM прогоняет компилятор много раз.
4. Прецедент — Go и Scala 3 пришли к тому же по тем же причинам.

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

• <T> (Rust/TS/Java/C#) — парсер-ambiguity, требует turbofish ::<> или backtracking; >> парсится как сдвиг.
• Контекстный парсинг с backtracking — медленнее, ошибки непонятнее.

Связь

• D27 — []T как тип массива, разделение с [T].
• D38 — явная передача параметров через Имя[T], без ::.
• 02-types.md — generic-параметры в декларации типов.

Эволюция

В ранних черновиках [T] означал и «массив», и «генерик». D27 расщепил: []T для массива, [T] только в позиции generic-применения.

D19. Match-arms через =>, не ->

Что

В match разделитель «образец → результат» — =>, не ->. Match-arm имеет две формы тела: pattern => expr (одно выражение) или pattern => { block } (блок). Match-arm — исключение из общего правила D40 «=> и {} не сочетаются».

Правило

-> — для типов и сигнатур:

fn f(x int) -> int                       // тип возврата
type Handler alias fn(Request) -> Response // функциональный тип через alias

=> — для тела и разветвлений:

match shape {
    Circle { r } => 3.14 * r * r
    Square { s } => s * s
}

ro inc = |x| x + 1
fn double(x int) -> int => x * 2

Match-arm с блоком — через => и {} (Rust-стиль):

match entry {
    Empty => insert_new(idx, key, value)        // одно выражение
    Occupied { value: old } => {                // блок через => { ... }
        @entries[idx] = Occupied { key, value }
        return Some(old)
    }
    Tombstone => {
        @tombstones -= 1
        @entries[idx] = Occupied { key, value }
        return None
    }
}

Грамматика:

match-expr = 'match' expr '{' { match-arm } '}'
match-arm  = pattern [ guard ] '=>' arm-body
arm-body   = expression | block
guard      = 'if' expr
block      = '{' { statement } [ expression ] '}'

«Параметры → тело» и «образец → результат» — одна семантика «дай мне это, я отдам тебе то», везде один символ =>.

Почему

1. Разделение ролей. -> декларативно (тип), => вычислительно (выражение). Глаз видит границу.
2. Прецедент. C#, F#, Scala 3, Rust унифицируют => для лямбд и match-arms.
3. AI-first. Один символ — одна роль, меньше путаницы у LLM.
4. => всегда в match-arm. Без => parser не отличал бы блок-arm от guarded-arm pattern if cond => expr или от вложенного блока внутри сложного pattern’а. => остаётся гарантированным маркером «начало результата».

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

• -> для match-arms (Rust до 1.0, OCaml/Haskell) — перегрузка с типом возврата.
• : (Python) — конфликт с record-литералами.
• then — лишнее ключевое слово ради того же эффекта.
• Блок-arm без => (pattern { block }). Без => теряется единый маркер «начало результата»; парсер хуже различает arm с блоком от arm с guarded-pattern и от нестед-блока в сложном pattern’е.

Связь

• D20 — сводная таблица стрелок.
• D22 — closure-light |x| без =>, closure-full fn(...) подчиняется D40 как named fn.
• D40 — общий закон «=> и {} не сочетаются» и match-arm как единственное исключение.

Эволюция

Старые примеры match ... -> result обновлены на =>.

D20. () вместо void, сводка стрелок, function type syntax

Что

Тип «без значения» — () (unit), не void. Плюс сводная таблица стрелок (каждая роль закреплена за одним символом) и обязательный fn-keyword для function type везде.

Правило

fn cleanup() Io -> ()           // явно
fn cleanup() Io                  // -> () можно опустить
ro xs [()] = [(), (), ()]       // unit как элемент массива
ro r Result[(), str] = Ok(())   // unit как generic-параметр

Сводка символов:

Один символ — одна роль.

Function type — всегда с fn префиксом

Function type записывается только через fn(args) Effects? -> Ret. Бесколонная форма (args) -> Ret запрещена во всех контекстах.

// ✓ — function type везде с fn
fn sort[T](xs []T, less fn(T, T) -> bool) -> []T
type Handler alias fn(Request) -> Response
ro callback fn() -> int = ...
type Server { handler fn(Request) -> Response }
fn measure[T](action fn() Io -> T) Time -> (T, Duration)

// ✗ — без fn запрещено
ro f () -> int = ...                      // ✗
type Handler alias (Request) -> Response   // ✗
fn sort[T](xs []T, less (T, T) -> bool)    // ✗
type Server { handler (Request) -> Response }  // ✗

Где конкретно fn нужен:

Почему fn обязателен

1. Парсер однозначен. Без fn парсер видит (int) -> bool и должен делать lookahead чтобы различить:

   • Group expression (parens around expression) в выражении.
   • Tuple type (int) в позиции типа (хотя одно-element tuple обычно не пишется в Nova).
   • Function type начало.

   fn ставит явный признак «дальше function type» — парсер не ошибается.

2. AI-friendly. LLM, генерирующая код, не путает функциональный тип с tuple/grouping. Один синтаксис для function type, один путь.

3. Согласованность с named-fn. fn name(args) -> Ret => body — именованная функция начинается с fn. Function type fn(args) -> Ret — то же начало. Это одна и та же концепция «function thing» — fn это её префикс.

4. D9 «один путь». Не два варианта (alias-form vs other-form). Везде одинаково.

5. Прецеденты. Rust (fn(i32) -> bool), Go (func(int) bool) — оба требуют function-type keyword. TypeScript/Kotlin/Swift не требуют, потому что у них grammar не имеет (x) group-expr ambiguity (разные приоритеты parsing). Nova с её парсером ближе к Rust/Go.

Не путать с closure

Function type (тип) — fn(int) -> bool. Closure value (выражение) — |x| x > 0 (light) или fn(x int) -> bool => x > 0 (full).

// Тип: fn(int) -> bool
ro pred fn(int) -> bool = |x| x > 0
//        ^^^^^^^^^^^^^^^^^      ^^^^^^^^^^^^
//        type annotation         closure-light value

// closure-full — анонимная fn (см. D22):
ro pred fn(int) -> bool = fn(x int) -> bool => x > 0   // closure-full
ro pred fn(int) -> bool = fn(x int) -> bool { x > 0 }  // closure-full block

fn встречается в трёх ролях, различимых по контексту:

• Декларация — fn name(...) ... (top-level statement-position).
• Тип — fn(int) -> bool (в type-annotation position).
• Closure-full — fn(x int) -> bool => body (в expression-position).

См. D22 для closure-light vs full.

Почему

1. () — обычный тип. Может быть generic-параметром, элементом массива, полем. void в C/Java — особый случай с дырами.
2. Двухсимвольное разделение яснее «всё через ->» (Rust) или «всё через =>»: глаз видит границу «тип / выражение».
3. Прецедент. Rust/Haskell/OCaml/Swift/Kotlin — ()/Unit как нормальный тип. Дыра void — известная боль во всех языках, где её оставили.

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

• void — не может быть generic-параметром (Result[void, E]), требует обходных путей.
• Везде один символ (-> или =>) — перегрузка, теряется визуальная граница.
• Третий символ (~>, :>) — экзотика без выигрыша.

Связь

• D19 — match-arm через =>.
• D22 — пересмотр: = больше не используется для тел функций.

Эволюция

Ранее = отделял тело именованной функции (fn f() = expr). D22 перенёс эту роль на =>, чтобы убрать дублирующий синтаксис. = теперь — только присваивание.

D22. Closure: light |...| и full fn(...)

Что

В Nova две взаимодополняющие формы closure:

1. closure-light — |params| body — компактная untyped форма. Без типов параметров, без -> T, без эффектов. Тело — bare expression ИЛИ block.
2. closure-full — fn(params T) Effects -> Type body — типизированная форма, идентичная named fn без имени. Тело — => expr или { block }, как у named fn (D40).

Эти формы не пересекаются: как только нужен хоть один тип параметра, return-type или эффект — переключаемся на fn(...). |...| — только untyped.

Тело именованной функции остаётся как было: => expr или { block } (D40). = — только для let.

Правило

closure-light

ro inc   = |x| x + 1                              // expr-body
ro zero  = || 0                                    // no params
ro block = |x| { ro y = x*2; y + 1 }              // block-body
ro any   = |_| 0                                   // wildcard

list.filter(|x| x > 0)                              // closure-arg
list.fold(0, |acc, x| acc + x)                      // multiple params
list.map(|_| 42)                                    // ignore element
spawn(|| compute())                                  // no-arg closure-arg

Грамматика:

closure-light = '|' params? '|' (expression | block)
params        = identifier { ',' identifier }
identifier    = name | '_'

В closure-light запрещено:

|x int| x + 1            // ❌ типы параметров — переключайся на fn(x int)
|x| -> int { ... }       // ❌ return-type — переключайся на fn(x) -> int
|x| Db -> R { ... }      // ❌ эффекты — переключайся на fn(x) Db -> R
|x| => x + 1             // ❌ нет `=>` в closure-light, body начинается сразу

closure-full

ro typed    = fn(x int) -> int => x * 2
ro block    = fn(x int, y int) -> int { ro z = x+y; z * 2 }
ro with_eff = fn(req Request) Db Log -> Response { process(req) }
ro void     = fn(s str) Log { Log.info(s) }

Грамматика идентична named fn без имени:

closure-full = 'fn' '(' params ')' [ effects ] [ '->' type ] body
body         = '=>' expression | block
params       = param { ',' param }
param        = identifier type            // тип обязателен

Inference и context-sensitivity

closure-light валиден только когда контекст однозначно задаёт сигнатуру. Источники контекста:

1. Параметр fn-call’а: list.filter(|x| x > 0) — sig из filter’а.
2. Annotated let: let f fn(int) -> int = |x| x + 1.
3. Return-position: fn make() -> fn(int) -> int => |x| x + 1.
4. Tuple-position при typed return: (|x| ...) если parent объявил -> (fn(int) -> int, ...).
5. First-use inference (Rust-семантика):

   ro f = |x| x + 1
   f(5)                    // first use фиксирует x: int → sig: fn(int) -> int
   f(3.14)                 // ❌ ошибка: sig уже зафиксирован
   

Если контекст недостаточен (closure-light нигде не используется):

ro f = |x| x + 1           // ❌ cannot infer signature

→ либо использовать f далее, либо переключиться на closure-full:

ro f = fn(x int) -> int => x + 1

Эффекты

closure-light никогда не пишет эффекты в сигнатуре. Эффекты, реально используемые в теле closure-light, должны:

• быть подмножеством contextual-sig’а, И
• покрываться ambient effect-set в точке создания closure’а (= эффекты enclosing-функции ∪ активные with-блоки).

fn process(users []User) Db -> []Result =>
    users.map(|u| Db.find(u.id))                   // Db: ✅ есть в parent

fn pure(xs []int) -> int =>
    xs.fold(0, |acc, x| acc + x)                   // эффектов нет — ✅

fn no_db(users []User) -> []Result =>              // Db в parent НЕТ
    users.map(|u| Db.find(u.id))                   // ❌ Db не доступен

closure-full эффекты пишет явно — она «полная» по сигнатуре:

fn make_handler() -> fn(Request) Db -> Response =>
    fn(req) Db -> Response { process(req) }

Эффекты на named fn остаются обязательными — D62/R1 «эффекты всегда видны в сигнатуре» не ослабляется. Inference применим только к closure-light, потому что closure-light не пересекает границу модуля.

Captures

Closure захватывает свободные переменные по ссылке через scope. Никаких move / &mut / lifetime — это не нужно благодаря managed-heap (D32, D62).

• Примитивы (int, bool, f64, …) — copy-by-value.
• Объекты (record, sum-type, array) — managed-reference, shared с enclosing scope.
• let mut переменные — closure модифицирует тот же slot; изменения видны снаружи и между вызовами closure’а.
• Escape — если closure уезжает за пределы создавшей fn, захваченные переменные автоматически живут в managed-heap.

fn make_counter() -> fn() -> int {
    mut count = 0
    || { count = count + 1; count }
}

ro f = make_counter()
ro g = make_counter()
f()    // 1   ← каждый вызов make_counter создаёт свежий scope
f()    // 2
g()    // 1   ← у g свой count, не shared с f

Несколько closure’ов, созданных в одном scope, разделяют capture:

fn make_counter() -> (fn() -> int, fn(int) -> int, fn() -> int) {
    mut count = 0
    (
        || { count = count + 1; count },
        |a| { count = count + a; count },
        || count,
    )
}

ro (f1, f2, f3) = make_counter()
f1()    // 1   ← все три closure'а share один count
f1()    // 2
f2(5)   // 7
f3()    // 7

Free-variable resolution

Свободные переменные резолвятся через lexical scoping на момент создания closure’а. Параметр одного closure’а не виден в теле другого:

mut count = 0
(|a| count += a, || a)                              // ❌ `a` undefined в `|| a`
//                  ^
//                  parameter of previous closure, not in scope here

Body-type matching

Тип тела closure (выводимый или явный) должен совпадать с ожидаемым return-type из contextual sig:

fn make() -> (fn() -> int, fn(int) -> int) =>
    (|| 0, |a| count += a)
//          ^^^^^^^^^^^^^ ❌ `count += a` returns `()`, sig expects `int`
//                          fix: |a| { count += a; count }

return в closure-light

return в |x| { ... } выходит из самого closure, не из enclosing fn. Это согласовано с D43 (return в trailing-block выходит из блока):

ro find = |xs []int| {
    for x in xs {
        if x > 100 { return Some(x) }                // выход ИЗ closure
    }
    None
}

Wildcard _ в параметрах

_ валиден как имя параметра в closure-light, closure-full и named fn — «параметр обязателен по арности, не используется в теле» (расширение D59):

list.map(|_| 42)
fn handle(req Request, _meta Meta) Db -> Response { ... }
fn(_x int, y int) -> int => y * 2

Почему

1. Освобождение =>. В Nova => — маркер тела (named fn, handler-method) и match-arm. Использование => в лямбдах создавало перегрузку и запрещало блок-форму. Closure-light с |...| убирает перегрузку: => остаётся только для тела/arm.
2. Two-level: light vs full. Untyped one-liner’ы (filter, map, fold) получают компактный синтаксис. Typed/effect-aware closures пишутся полной формой fn(...), идентичной named fn — нет специальной грамматики anonymous-typed.
3. Парсер коммитится за один токен. |...| в expression-position решается мгновенно (binary | без LHS невозможен). Старый (params) => требовал unbounded look-ahead.
4. Trailing и closure ортогональны. closure-light только в expression-position. Trailing — через fn(...) или zero-param {} (D43). Парсер не путает.
5. Anonymous fn возвращается. D22-old запрещала fn(...) без имени; новая D22 разрешает её как closure-full.
6. Блок-форма для closure-light. |x| { stmts; expr } теперь разрешено — старая D22 явно запрещала => { block }, что заставляло выносить любую closure с let в named fn.
7. Captures без move/lifetime. Managed-heap (D32) делает escape автоматическим.

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

• (x) => expr (D22-old) — перегружает =>, требует unbounded look-ahead, не имеет блок-формы.
• x => expr без скобок (JS-style) — не решает look-ahead для multi-param случая, оставляет => перегруженным.
• fn(...) без типов (overlap с |...|) — две взаимозаменяемых формы создают выбор без правила. Граница «типы есть → fn, нет → |...|» чёткая.
• Effect inference на named fn — отказ от R1 «эффекты всегда видны в сигнатуре». Inference допустим только для closure-light.
• move-keyword / lifetime-маркеры — managed-heap автоматизирует escape.
• Implicit it — нелокальный reasoning, плохо для AI.
• Trailing closure через |x| — func(args) |x| body создавал ambiguity с binary |. Trailing с params — только через fn(...), см. D43.
• => { block } для closure-light — closure-light не использует => вообще. Тело всегда либо bare expression, либо block.

Связь

• D19, D20 — => остаётся в match-arm как маркер «начало результата».
• D40 — правило «=> и {} не сочетаются» применяется к named fn, closure-full, handler-method. closure-light имеет отдельную грамматику.
• D43 — trailing с params через fn(...), без params — { block }. |...| в trailing-position запрещён.
• 04-effects.md → D31 — handler-method, как fn, имеет две формы тела.
• D62 — closure-light наследует ambient effect-set.
• 02-types.md → D32 — captures через managed-heap.

Эволюция

Пересмотр D20: = исключён из «тел функций», его роль принял =>.

Ревизия (2026-05-1): «лямбда строго (params) => expr, без блок-формы».

Ревизия (2026-05-10): полная замена (params) => на two-level closure: |x| (light, untyped) + fn(...) (full, typed). Триггер — семантический перегруз =>, look-ahead в парсере, запрет блок-формы лямбды, унификация с trailing-block. Anonymous-fn запрет (D22-old) снимается — fn(...) без имени = closure-full. Block-форма closure возвращается. Migration: ~30 примеров в spec/, патч parser/interp, план — docs/plans/19-closure-and-error-ops.md.

D23. return — только для раннего выхода

Что

return есть, но используется исключительно для guard-clauses / ранних выходов. Последнее выражение тела — автоматически результат.

return — это statement, поэтому он встречается только в блок-форме тела (fn name(...) { ... }). В =>-теле (где должно быть ровно одно выражение, D40) guard-clauses через return не пишутся: либо вся функция выражается одним match/if (тогда =>-тело подходит), либо нужны guard’ы — и тогда блок-форма.

Правило

Разрешено:

// блок-форма с guard'ами
fn classify(x int) -> str {
    if x < 0  { return "negative" }
    if x == 0 { return "zero" }
    "big"                              // последнее выражение = результат
}

fn process(req Request) Db Fail -> Response {
    if req.method == "GET" { return next(req) }
    do_work(req)
}

// =>-тело: одно выражение, return не нужен
fn classify(x int) -> str => match x {
    n if n < 0  => "negative"
    0           => "zero"
    _           => "big"
}

Запрещено линтом (избыточно):

fn double(x int) -> int => return x * 2     // лишний return; и =>-тело
                                            // вообще не допускает statement'ов
fn classify(x int) -> str {
    if x < 0 { return "n" } else { return "p" }   // обе ветки return
}

Если все ветви заканчиваются return — переписать через match/if как выражение и использовать =>-тело.

Запрещено грамматически:

// =>-тело допускает ровно одно выражение, а не цепочку statement'ов
fn classify(x int) -> str =>
    if x < 0  { return "negative" }      // ← statement, не expression
    if x == 0 { return "zero" }
    "big"

Семантика:

• return в closure-light (|x| body) — выходит из самого closure, не из enclosing fn (D22). Аналогично return в trailing-block.
• return в closure-full (fn(...) body) — выходит из closure (точно как named fn).
• return в match-arm — match-arm тоже строго pattern => expr (D40), поэтому return в arm тоже отсутствует. Если в arm нужен ранний выход — match вынесен в блок-форму fn, и return стоит после match’а.
• return в with-блоке (block-body) — выходит из enclosing-функции.
• return в trailing-block (D43) — выходит из самого блока (это блок, не лямбда), не из enclosing fn.

Почему

1. Guard-clauses естественно пишутся в блок-форме — middleware, валидация, ранние выходы.
2. AI-first. LLM рефлекторно генерит return — полный запрет требовал бы переучивания.
3. Один стиль на функцию. Линт против избыточного return в последней позиции.
4. Прецедент. Rust идиоматически использует return только для ранних выходов.
5. => строго одно выражение. Раньше D23 разрешал чередование guard-if {return} + финальное выражение в =>-теле. Это нарушает «=> = одно выражение» (D40); убрано — guard’ы только в блок-форме.

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

• Полное отсутствие return (OCaml/Haskell) — заставляет вкладывать if/else глубже.
• break/done — нестандартно, без выгоды.
• return обязателен (Go/Java) — противоречит «функция = выражение».
• Guard-цепочки в =>-теле (как было в старой D23). Конфликтовало с D40 — =>-тело это одно выражение, statement-цепочки требуют блок-формы.

Связь

• D22 — return в closure-light и closure-full выходит из самого closure, не из enclosing fn.
• D19 — match-arm строго pattern => expr или pattern => { block }; return в arm выходит из enclosing fn (т.к. arm не функция).
• D40 — => и {} не сочетаются; guard-цепочки требуют блок-формы.

Эволюция

Ревизия (2026-05): убраны примеры guard-clauses в =>-теле fn. Раньше D23 допускал fn classify(x) -> str => if x<0 {return "n"} ... "big" — цепочка statement’ов после =>. Это противоречило D40 («=> = ровно одно выражение»). Теперь правило единое: guard’ы только в блок-форме fn name(...) { ... }.

D27. Синтаксис массивов: []T префикс, [N]T фиксированные

Amended (Plan 138 D239, 2026-06-10): []T теперь синтаксический псевдоним Vec[T] (D239). Синтаксис записи не меняется, семантика — меняется: []T ≡ Vec[T] на уровне типов.

arr[i] для типов реализующих Index[K, V] (D238) — десугаринг в arr.index(i) вместо compiler built-in. []T / Vec[T] реализует Index[int, T] и Index[Range, Vec[T]] (zero-copy slicing).

Amended ([M-fixed-array-value-semantics], 2026-07-10): [N]T — value-класс. Layout-обещание этого блока («[N]T — N подряд, без указателя») теперь нормативная семантика хранения И копирования, а не только раскладка:

1. Inline-хранение. [N]T живёт по месту — в стек-кадре у локала, внутри объекта у поля record’а (C: T name[N];). Никакого heap-указателя и len/cap-заголовка: N — компайл-тайм константа типа. (До амендмента имплементация кучевала [N]T наравне с []T — это ретрактировано.)
2. Копирующая семантика. Присваивание/передача/возврат следуют value-правилам (D216 §V3.1, таблица value-типов — [N]T включён): mut b = a — независимая копия (мутация b не видна в a); параметр по умолчанию — ro-представление (копия либо скрытая ссылка на выбор компилятора, ненаблюдаемо — D326 Р10); mut x [N]T — in-out ссылка (мутации видны вызывающему, единый канон D326 Р3/Р10); -> [N]T — возврат по значению.
3. Элементы могут быть кучевыми. [N]str / [N]*T / [N]Vec[T] — контейнер остаётся inline value; элементы-указатели сканируются GC по месту (consecutive-стек и heap-объекты Boehm сканирует консервативно — пейлоады удерживаются на протяжении жизни массива).
4. Bounds-check. arr[i] / arr[i] = v паникуют при OOB по компайл-тайм N (сообщение как у []T: «array: index i out of bounds for length N»); элизия на доказанных in-range сайтах — та же политика D257, что у []T.
5. Литералы. [e0, …, eN-1] в [N]T-позиции обязан иметь ровно N элементов; ...spread в [N]T-литерале запрещён (N фиксирован). Оба нарушения — ошибка компиляции.

[]T-часть блока (Vec-канон D239) не затронута. Открывает SocketAddr { image [20]u8 } без аллокаций (174.5-связка). Тесты: nova_tests/fixed_array/ (pos+neg+panics), GC-удержание — gc_forced_collect.nv.

Amended (D440, 2026-07-21): [N]T @len() / @ptr() accessors. [N]T получает зеркало Vec/str-поверхности — arr.len() (компайл-тайм N) и arr.ptr()/mut-перегрузка -> *mut T (адрес первого элемента). Компилятор-синтез (НЕ .nv-декларация — method-level const-generic N в языке отсутствует). Подробности — D440.

Amended (221.1 №24, 2026-07-23, ОКНО-4, владелец: путь (б)): [](T1, T2, ...) — []T-алиас как ТИП в EXPRESSION-позиции, когда T сам требует скобок (кортежный тип-элемент). До амендмента [] в expression-позиции ВСЕГДА парсился как пустой литерал (Vec/array-или- map, D38), а следующая (...) — как ВЫЗОВ этого литерала: [](str, str).new() давало мутную [E7330] str is a record type, not a value (компилятор ошибочно диагностировал bare-имена типов str как value-аргументы вызова, вместо распознавания намерения пользователя — «тип (str, str) как элемент Vec»). Канон требовал многословной формы Vec[(str, str)].new().

Вызов пустого литерала как функции — ВСЕГДА ошибка (значение, а не функция); эта грамматическая позиция была семантически СВОБОДНА для переиспользования. Правило: если непосредственно за пустым [] в expression-позиции следует СКОБОЧНАЯ тип-форма ((T1, T2, ...) — кортежный тип, тот же parse_type(), что и в любой другой тип-позиции) И следом идёт ГЕНУИННОЕ продолжение типа-как-значения (. или {) — парсер трактует ВСЮ конструкцию [](T1, …) как Vec[(T1, …)] (идентичная TurboFish-форма, что и явно написанный Vec[(T1, …)] — переиспользует 100% существующей static-dispatch машинерии, никакого нового codegen/typecheck-пути). Lookahead — спекулятивный с rollback (симметрично try_parse_turbofish_args): если скобочная форма НЕ парсится как тип, или после неё нет ./{, парсер откатывается к СТАРОМУ разбору (пустой литерал + вызов) — оригинальная диагностика на ДЕЙСТВИТЕЛЬНО некорректном вызове (ro y = [](str, str) без продолжения) сохраняется байт-в-байт (E7330, как и раньше).

Простая (не кортежная) форма []T.new() (bare Ident сразу после [] + .) — существующий D38-механизм (Path(["__array", T])), амендментом НЕ затронута/не переписана — обе формы ([]T.new() и [](T1, T2).new()) канон, независимые пути.

Канонизация существующих Vec[(-сайтов (если такие найдутся в других пакетах) — ВНЕ объёма этого амендмента (отдельная волна по решению владельца). Фикстуры: spec_tests/conformance/d27_array_type_expr_ position.nv (pos — tuple-форма + простой-T регресс + push/index + Vec[(…)]-baseline), spec_tests/conformance/neg/array_type_expr_ position_neg.nv (neg — E7330 сохранена для генуинно некорректного вызова).

Что

Массивы записываются префиксом (Go-стиль): []T динамический, [N]T фиксированный, [N1][N2]T многомерный — порядок размеров совпадает с порядком индексации.

Правило

ro xs []int = [1, 2, 3]                // динамический
ro buf [5]u8 = [0, 0, 0, 0, 0]         // фиксированный
ro zeros [4]u8 = [0; 4]                // повторение через ;

ro matrix [2][3]int = [[1, 2, 3], [4, 5, 6]]
matrix[i][j]                             // i: 0..2, j: 0..3 — порядок совпадает

ro opt Option[int] = Some(42)           // generic не меняется

Парсер по позиции:

• В позиции типа без имени слева — массив ([]T, [5]T).
• В позиции типа после имени — generic (Option[T]).
• В позиции выражения — индексация (arr[i]).

Layout: [N]T — N подряд, без указателя. []T — { ptr, len, cap }, 24 байта на 64-bit. [N1][N2]T — плоский row-major. [][]T — jagged (массив указателей на массивы).

Почему

1. Соответствие индексации — [2][3]int ↔ arr[i][j]. В Rust [[T; 3]; 2] порядок обратный; программисты ошибаются.
2. Парсер однозначен — [ различается по позиции в грамматике.
3. Чтение слева направо — «массив 2×3 целых».
4. Generic не страдает — Option[T] остаётся.
5. Прецедент Go.

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

• Java T[] / int[2][3] — парсер сложнее, конфликт с Option[T].
• Rust [T] / [[T; N]; M] — обратный порядок размеров, конфликт «массив vs generic» одного символа.
• [T; N] для одномерного — ; читается странно в многомерных, нет соответствия индексации.

Связь

• D16 — [T] теперь только generic-применение.
• D38 — static-методы на типе массива ([]T.with_capacity(n)).
• 02-types.md — sum/record не конфликтуют по грамматике.

Эволюция

Старо: [T] динамический, [T; N] фиксированный — конфликт с generic. Перешли на Go-style; ~50 мест в документах исправлено.

D440. FixedArray len и ptr аксессоры (Plan 200 П19, 2026-07-21)

Source: Plan 200 Пункт 19. Status: ✅ ACTIVE. Связь: D27 ([N]T value-класс, амендмент выше), D238 (arr[i] — та же структурная FixedArray-магия), D299 (@ptr()/@len() пара — Vec/str-прецедент, зеркалируемый здесь).

Что

[N]T (fixed-array value-тип) получает два ресивер-метода, зеркало Vec/str-поверхности:

fn [N]T @len() -> int    // компайл-тайм N, O(1), без рантайм-обвязки
fn [N]T @ptr() -> *T     // адрес первого элемента; ro-ресивер
fn [N]T mut @ptr() -> *mut T  // та же форма, mut-ресивер (перегрузка по мутабельности)

Правило

• arr.len() — целочисленная константа N из типа ресивера arr ([N]T). Не читает никакого рантайм-поля (у [N]T нет len/cap заголовка, D27-амендмент — inline T data[N]).
• arr.ptr() — указатель на первый элемент, *T (ro, D246 *T ≡ *ro T default) когда arr связан ro, *mut T когда arr связан mut (перегрузка по мутабельности ресивера — тот же паттерн, что у Vec[T] @ptr() / Vec[T] mut @ptr(), std/collections/vec/access.nv:262/270). Значение указателя safe получить без unsafe; разыменование (p.read()/p.write(v)/p[i]) требует unsafe { } — контракт идентичен Vec[T] @ptr() / str @ptr().
• Lifetime (доккомент, НЕ enforcement): для стекового [N]T (локал, не-priv-поле record’а на куче) вид, полученный через @ptr(), не переживает скоуп владельца — тот же неформальный контракт, что у Vec[T] @ptr()’s «pointer invalidated by reallocating mutation» (там — realloc, здесь — конец стек-фрейма). Компилятор это НЕ проверяет (в языке нет lifetime-анализа/borrow-checker’а); документируется как обязательство вызывающего, зеркало существующей практики.
• @len()/@ptr() — НЕ unsafe fn (сама операция safe); unsafe нужен только на стороне вызывающего для разыменования результата @ptr().

Почему

Компилятор-синтез, не .nv-декларация. Method-level const-generic N в языке отсутствует — ресивер-форма fn [N]T @m() { ... } с N как ссылающимся на РАЗМЕР типа не парсится (проверено пробой: fn [4]u8 @probe() -> int => 4 → error: expected identifier, got int literal на 4 внутри [4]). Написать один .nv-текст на ВСЕ N невозможно; писать N деклараций (одну на каждый использованный размер) — дублирование, D9. Компилятор синтезирует обе операции структурно из TypeRef::FixedArray(N, elem) — тем же механизмом, каким уже резолвится arr[i] (D238-семья, [M-fixed-array-value-semantics] амендмент к D27 выше): чекер извлекает (N, elem) напрямую из типа ресивера (НЕ через method_table, никакой .nv-сигнатуры не существует), кодоген распознаёт тот же _NovaFixArr_<N>_..._<elem> C-struct-паттерн, что уже использует arr[i]-чтение, и эмитит N-литерал / адрес data[0] напрямую. Один резолв-путь для всей FixedArray-поверхности (§3 one-window) — @len/@ptr не заводят отдельную name-keyed диагностическую/диспетчерскую ветку в стороне от @index.

Мотив (Plan 200 П19, три реальных упора одной недели): (1) pad-оптимизация не могла собраться — RawMem.copy из fill_bytes [4]u8 не имел указателя-источника; (2) потребители encode_utf8 писали байты циклом push вместо копии среза; (3) generic-fallback @display примитива — стек-буфер [32]u8 был невыразим без каста в холодной ветке. Обход существовал (&arr as *T, прецедент from_bits), но это каст-жест на каждом сайте вместо именованной двери — @ptr()/@len() дают ту же дверь, что уже есть у Vec[T]/str.

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

• .nv-декларация с method-level const-generic N. Языка-уровня const-generic’ов нет (см. «Почему») — потребовало бы нового синтаксиса ради двух accessor’ов; непропорционально.
• N отдельных .nv-деклараций (по одной на каждый встреченный размер). Дублирование без предела — каждый новый [7]u8/[64]u8 в проекте требовал бы своей копии тела. Нарушает D9.
• Enforcement lifetime-контракта у @ptr(). У языка нет borrow-checker’а/lifetime-анализа (осознанный компромисс всего проекта, не локальное решение здесь) — контракт документируется, как у Vec[T] @ptr(), а не проверяется статически.

Реализовано в

compiler-codegen/src/types/mod.rs (peel_fixed_array + fixed_array_accessor_return, вызываются из infer_expr_type’s Call-арма и infer_method_call_channel_type — та же пара продюсеров, что и любой другой instance-call); compiler-codegen/src/codegen/emit_c.rs (emit_call’s Member-арм, синтез через существующую parse_mono_fixed_array_name — ту же функцию, что и arr[i]-чтение). Тесты: spec_tests/conformance/ (standalone) — pos (.len(), .ptr() + RawMem.copy round-trip, mut-перегрузка запись), neg (bare arr.len без скобок — обычная диагностика, не новая форма). D440 NEW.

D30. Стиль именования

Что

Один стиль на весь язык: PascalCase для типов и протоколов, snake_case для функций/полей/локальных, SCREAMING_SNAKE_CASE для констант. Акронимы — PascalCase без исключений.

Правило

Акронимы PascalCase, не UPPERCASE:

type Db effect { ... }          // не DB (эффект — protocol)
type Io effect { ... }          // не IO
type Url str                 // не URL (newtype над str)
type Http effect { ... }        // не HTTP
type JsonValue { ... }       // не JSON (record)
type SqlBuilder { ... }      // не SQL (record с полями)

Договорные конвенции имён методов:

Оси семантические (вид / трансформация / потребление) — следуй им; as_-префикс упразднён (D410).

try_* / failable pair convention (D30 §2, Plan 108):

Когда операция может завершиться с ошибкой, определяются две формы:

Правило реализации: op реализуется как Nova-body через try_op:

// Примитив — только эта функция знает как читать байт:
export external fn ReadBuffer mut @try_read_byte() -> Result[u8, ReadBufferError]

// Обёртка — один лайнер на Nova, без дублирования C-логики:
export fn ReadBuffer mut @read_byte() Fail[ReadBufferError] -> u8 => @try_read_byte()!!

Зачем try_* первичен:

• C-логика живёт в одном месте (try_*), * = тонкая обёртка
• Нет дублирования кода ошибок между парами
• Вызывающий выбирает стиль: op() (throw-style) или try_op() (result-style)

Применяется везде: ReadBuffer, WriteBuffer, I/O, парсинг, преобразования типов.

Полные слова, не сокращения

Имена методов, типов, параметров и полей — полные слова, не сокращения. Приоритет — читаемость, а не количество символов.

fn ReadBuffer    @position()  -> int     // не @pos()

fn copy_into(destination []u8) -> ()   // не dest
fn parse(input str) -> Result[T, E]      // не buf, не val

Запрещены ad-hoc сокращения (mainstream-precedent): pos, dest, src, buf, val, tmp, cnt, idx (кроме mainstream-исключений ниже), arr, len (кроме mainstream-исключения), msg (кроме Error.msg field — закреплено D26), cfg, ctx.

Mainstream-исключения (Rust/Go/Swift convention — слишком устоявшиеся формы, чтобы менять):

Ровно четыре исключения, никаких других. Остальные — full word: length если не коллекция-len, capacity если не свойство-cap, iterator если не protocol-имя, index если параметр или поле.

Operator-overloading имена (D46) — @plus, @rem, @neg, @shl, … — фиксированы и не подчиняются правилу полных слов. Это исторически зацементированная convention из Rust/C++/Swift; менять @plus → @addition бессмысленно.

Acronyms работают по правилу выше (PascalCase в типах, snake_case в методах: JsonParser, parse_json). К full-word правилу не относятся.

Зачем строго:

1. AI-friendly. LLM не должна угадывать когда pos это position, а когда posix. Один canonical full word — однозначность.
2. Code review consistency. Reviewer видит dest и спрашивает «destination or destruct?» — лишний cycle. Full word убирает класс багов.
3. Прецедент Swift API Guidelines. Swift строго запрещает abbreviations, и это даёт API surface, которую читать как естественный язык.

Leading underscore: «параметр / биндинг намеренно не используется»

Конвенция (Plan 110.7.3.a, 2026-06-01): локальные биндинги и параметры с префиксом _ явно сигналят compiler’у «эта переменная объявлена для интерфейсной совместимости, но не нужна телу». Это подавляет W_UNUSED_PARAM / W_UNUSED_LOCAL warning’и без необходимости комментариев.

Правило компилятора:

• Имя начинается с _ (включая чистый _) → unused-warning suppressed.
• Любое другое имя → warning fires если binding не читается.
• _ (одиночное подчёркивание) — традиционная «throwaway» форма; допустимо использовать многократно в одном scope (каждое — fresh binding).

Prior art:

• Rust: let _x = compute() — same convention.
• Swift: _ parameter labels — call-site suppression.
• Go: _ blank identifier — same purpose, syntax level.
• Python: _var — informal convention, no enforcement.

Запрещено: _ префикс на public exports — это signals «private to module», и leading-underscore tied к unused-suppression cleanly разделимо только для local / private bindings.

Типы ошибок: Parse<TypeName>Error, <Operation><Domain>Error

Имена ошибок в публичных API должны включать тип / домен который породил ошибку, а не быть generic-словом:

Не использовать generic-имена:

Вариантам внутри sum-типа доменный префикс не нужен — они уже живут в namespace своего типа:

type ParseComplexError enum InvalidFormat | NotANumber

throw InvalidFormat                          // имя варианта без префикса
throw ParseComplexError.InvalidFormat        // полная форма (если ambiguous)

Это согласовано с D65 lookup’ом: throw InvalidFormat находит активный Fail[ParseComplexError] handler по типу варианта.

Видимость полей record/tuple — через priv keyword (Plan 124, D220); default = public. Convention _prefix для conventionally-private полей отменена 2026-06-02 в пользу compile-time priv (07-modules.md → D47 amend). Для функций/методов видимость через export / приватно (07-modules.md → D47).

Зарезервированные имена для operator overloading: @plus, @minus, @times, @div, @rem, @neg, @or, @and, @xor, @shl, @shr, @eq, @lt, @le, @gt, @ge, @not, @get, @set — D46.

Test-имена — строки естественного языка: test "insert and get" { ... }.

Длина имени типа: минимум 2 символа (D30 §naming, Plan 167)

Запрещены однобуквенные имена типов (type T, type S, type K, …).

Таблица в D30 закрепляет T, K, V, E, … как конвенцию для generic-параметров (fn[T] ...). Если объявить type T { ... }, компилятор не может отличить «named type T» от «typevar T» в generic context — это источник E_PREFIX_SHADOWS_NAMED_TYPE. Запрет однобуквенных имён делает пространства имён непересекающимися.

type T { ... }       // ✗ E_TYPE_NAME_TOO_SHORT — переименуй в TVal, TNode, ...
type S { ... }       // ✗ E_TYPE_NAME_TOO_SHORT
type Db effect { }   // ✓ — 2 символа
type Ok { }          // ✓ — 2 символа

Error: E_TYPE_NAME_TOO_SHORT (Plan 167, D30 §naming).

Почему

1. Одно правило без исключений для акронимов — программисту и LLM не помнить «2 буквы UPPER, 3+ Pascal».
2. Composability — HttpClient, JsonParser читаются без «плотностей» из заглавных. Сравни HTTPClient, JSONParser.
3. AI-friendly. LLM плохо угадывает «сколько букв в акрониме» — единое правило.
4. Прецедент. Swift API Guidelines, современный .NET, Rust.

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

• Java/C# до 2010-х (UPPERCASE для коротких акронимов) — каша на стыке (parseXMLForJSONFromHTTPResponse).
• snake_case для всего (Python) — типы и значения визуально не отличаются.
• camelCase для функций (Java/JS) — to_str читается лучше toStr; границы слов чётче.

Связь

• 07-modules.md → D47 — export / приватно; стиль не зависит от видимости.
• D33 — SCREAMING_SNAKE_CASE для const.
• D46 — зарезервированные имена.

D33. Три оси immutability — ro/mut/consume + const + per-field freeze

Plan 114 rewrite (2026-05-31): эта секция полностью переписана. Старая формулировка («const vs let — compile-time vs runtime») декларировала три оси, но одна была fake: ось «const = compile-time, let = runtime» не соответствовала реальности после Plan 14 Ф.2 (расширил const на non-constexpr RHS через lazy-init nova_const_<name>() static getter). Plan 114 Ф.9 narrow’ит const обратно до strict constexpr-only, делая ось «hard compile-time guarantee» правдивой; Ф.10 generalize’ит const на 3 позиции; let retracted. Полный дизайн см. D184.

Что

Nova V2 имеет три ортогональные оси, все три реальные:

Правило

// Ось 1: binding mutability + ownership
ro x = 5                            // immutable binding
mut counter = 0                     // mutable binding
counter = counter + 1               // OK — mut
consume sb = StringBuilder.new()    // owned binding (Plan 73.1)

// Ось 2: const — hard compile-time guarantee
const MAX_PAYLOAD = 4096            // ✓ literal
const TIMEOUT_SEC = 60 * 5          // ✓ constexpr arithmetic
const ORIGIN Point = { x: 0.0, y: 0.0 }  // ✓ constexpr record-literal

const COMPUTED = make_point(7, 14)  // ✗ E_CONST_NOT_CONSTEXPR
                                    //   hint: «use `ro` for lazy-init»

// Module-level non-constexpr → ro (заменяет старый let X = …)
ro NOW = Time.now()
ro COMPUTED Point = make_point(7.0, 14.0)

// Ось 3: per-field freeze
type Account {
    ro id u64                       // never-mut, даже у `mut acc`
    balance int                     // default — mut если binding mut
    mut log_count int               // always-mut, даже у `ro acc`
}

const требует (strict constexpr-only — Plan 114 Ф.9):

• Литералы любого primitive-типа.
• Арифметика/bitwise/comparison над constexpr операндами.
• Record-литерал из constexpr-полей.
• Sum-type конструктор из constexpr args.
• Ссылка на другой const.
• Вызов const fn с constexpr args (Plan 114 Ф.11; см. D199).

Не runtime call, не effect, не allocation. Для lazy-init runtime-value используется ro X = … на module-level (заменяет старый let X = … host).

Strict module-level partition

На module-level между const и ro — обязательное разделение по constexpr-eligibility:

Compiler определяет «constexpr» точно — user не выбирает между const/ro, выбирает RHS, keyword следует. Codemod auto-converts в обе стороны.

Scope-level — без strict-правила. Внутри fn body ro x = 5 и const x = 5 оба валидны; разница только в гарантиях (const = строго constexpr

• inlined; ro = runtime immutable binding).

Статус реализации (обе стороны — implemented). Обратное направление (E_CONST_NOT_CONSTEXPR на не-constexpr const X) реализовано в Plan 114.4 Ф.1. Прямое направление (E_RO_FOR_CONSTEXPR_PREFER_CONST на constexpr-eligible module-level ro X) реализовано в Plan 148 Ф.3 (аменд D199 ниже). Оба направления используют один и тот же предикат constexpr-eligibility (check_const_constexpr_ex), поэтому не могут разойтись в определении «constexpr». Прямое правило применяется только к module-level binding с одним именованным binder’ом (ro NAME = …; UPPER_CASE binder парсится как single-segment unit-variant pattern и трактуется как имя); destructuring (ro (a, b) = …) и scope-local ro — не затрагиваются.

Почему

1. Compile-time гарантия (восстановлена). const теперь делает то что обещает — hard constexpr. После Plan 14 Ф.2 это было размыто; Plan 114 Ф.9 narrow’ит обратно.
2. Размеры массивов. [N]T (D27) требуют const N (теперь N может быть scope-local — Plan 114 Ф.10).
3. Associated constants. type T { const X = … } — namespace-bound constexpr (Java static final, Rust impl T { const X }, Kotlin companion const val). См. D200.
4. AI-first. LLM, видя const X = compute(...) → compile error E_CONST_NOT_CONSTEXPR, получает явный сигнал «используй ro».

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

• let/let mut — retracted в Plan 114 (D184). Сейчас replaced тройкой ro/mut/consume.
• := (Go) — дублирует binding declaration; источник shadowing-багов.
• final (Java) — лишнее ключевое слово.
• Без разделения — массивы [N]T потребуют литералов всюду; comptime станет несовместимым.

Сравнение с mainstream — см. D184 §«Сравнение с mainstream»

Связь

• D27 — const N для [N]T (Plan 114 Ф.10: any visible scope).
• D30 — SCREAMING_SNAKE_CASE для const.
• D32 — default immutable (ro ось 1).
• D36, D175, D176 — ro/mut field, ось 3.
• D102 — default-param values reference const.
• D184 — master keyword refresh decision (Plan 114).
• D199 — const fn comptime evaluable.
• D200 — associated constants.
• 07-modules.md — export const экспортирует.

D33-LEGACY (archived). const vs let — compile-time vs runtime

⚠ Эта секция — historical record для legacy-codebase reference. Plan 114 retracted let keyword (D184); design rewritten выше.

Что (archived)

const — для compile-time констант, известных при компиляции. let — для runtime значений (immutable binding); let mut — mutable. Это два разных ключевых слова, не сахар.

Правило

// const — compile-time
const MAX_PAYLOAD = 4096
const TIMEOUT_SEC = 60 * 5            // арифметика над литералами
const GREETING = "hello"

// let — runtime
ro now = Time.now()
ro user = Db.find(user_id) ?? throw UserNotFound(user_id)

// let mut
mut counter = 0
counter += 1

const требует:

• Compile-time computable: литералы, арифметика, конструкторы record/sum-type из const-значений.
• Не runtime-вызовы, эффекты, ссылки на не-const.

const fn (compile-time функции) — ✅ реализовано в Plan 114.4.2 (D199): функция с const-params + -> const T return вычисляется компилятором, call sites заменяются литералом в AST. См. D199. const NOW = Time.now() остаётся ошибкой (Time.now() — runtime call, не const fn).

const живёт в data-segment (zero-cost). let-объекты — в managed heap (или на стеке через escape analysis).

Почему

1. Compile-time гарантия. const — программист уверен, нет runtime-зависимостей.
2. Размеры массивов. [N]T (D27) требуют const N для имени.
3. const явно говорит «в data-segment», не нужно угадывать.
4. AI-first. LLM, видя const X = compute(...) → compile error, получает явный сигнал «используй let».

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

• := (Go) — дублирует let; источник shadowing-багов в Go.
• final (Java) — лишнее ключевое слово рядом с let.
• Без разделения — массивы [N]T потребуют литералов всюду; comptime станет несовместимым.

Сравнение с ro / mut field — три оси immutability

Nova имеет три разных keyword’а связанных с immutability — let, const, ro/mut field. Они не конкурируют, потому что работают на разных уровнях программы:

let / let mut — про binding

ro x = 5             // binding x не переприсваивается
mut y = 0         // binding y переприсваивается
y = y + 1

Default immutable (D32) — let без префикса всегда immutable. let mut — явный opt-in в mutable, аналогично Rust let mut, Swift var, Kotlin var. Программист видит let mut — знает что переменная меняется.

const — про compile-time

const MAX = 4096                  // compile-time, в data-segment
ro limit = compute_limit()        // runtime, в heap/stack

Оба immutable. Разница — const накладывает требование compile-time computability (литералы + арифметика над ними + const-record’ы). let принимает любое runtime-выражение.

const нужен для:

• Размеров фиксированных массивов: [N]T (D27) требует const N.
• Compile-time оптимизаций (свёртка, размещение в data-segment).
• Семантической декларации «это всегда константа», не «immutable до scope-exit».

ro / mut field — про поле record’а

type Account {
    ro id u64        // поле never-mut, даже у `let mut acc`
    balance money          // поле default — mut если binding mut
    mut log_count int      // поле always-mut, даже у `let acc`
}

mut acc = Account { id: 1, balance: 100, log_count: 0 }
acc.balance = 200          // OK   — поле default + binding mut
acc.id = 999               // ERR  — id ro
acc.log_count += 1         // OK   — log_count mut

ro / mut per-field — это freeze/unfreeze конкретного поля относительно дефолта. Они не пересекаются с let/let mut: binding управляет «можно ли модифицировать переменную», поле управляет «можно ли модифицировать конкретное поле в записи».

Пример где они комбинируются:

Почему три, а не одно

Альтернативы и почему они хуже:

1. Только let/let mut без const — массивы [N]T требовали бы compile-time выводимости из let N = 5. Компилятор должен проводить escape-analysis на каждый let, чтобы понять const-eligible. Программист не видит явно «это compile-time», а получает компилятор-error при первом нарушении. AI-unfriendly.

2. Только let/let mut без ro/mut field — потеря per-field freeze. Альтернатива — newtype wrappers (type AccountId(u64) для каждого immutable поля), что ведёт к verbose-коду и потере ergonomics (acc.id.value() вместо acc.id). Cell/RefCell-style wrappers (как в Rust) ещё хуже для AI-кодинга.

3. Только const/ro (без let/let mut) — теряем обычные mutable переменные в функциях. Можно через field record’а (тип-обёртку Counter { mut value int }), но это противоестественно для локальных счётчиков.

Это три разные оси ответственности, каждая решает свою задачу:

• let/let mut — binding mutability (можно ли переприсвоить).
• const — compile-time vs runtime placement.
• ro/mut field — per-field freeze в record’е.

Связь

• D27 — const для размеров фиксированных массивов.
• D30 — SCREAMING_SNAKE_CASE для const.
• D32 — default immutable bindings; mut для переменных и параметров.
• D36 — ro/mut модификаторы полей record’а; per-field freeze.
• 07-modules.md — export const экспортирует.

D34. Pattern-bind в if/while conditions — unified grammar с match arms

Status: active (Rust 1:1, 2026-05-27); amended Plan 114 D184 (2026-05-31): drop outer let keyword; identifier-pattern требует ro/mut; constructor/destructure pattern bare = immutable, mut inside; consume запрещён в conditions; outer-mut запрещён. AMEND (2026-07-25, реестр 221.1 №95): парсер-энфорс ретракции — if let/while let (Rust-style outer let) до этого момента тихо принимались парсером наравне с каноном («две двери»); теперь дают E_IF_LET_RETRACTED со span на let. Пишите паттерн напрямую: if Some(x) = expr { ... } / while Some(x) = expr { ... }. AMEND (2026-07-25, реестр 221.1 №106, [M-ro-launder-pattern-bind-not- enforced]): «bare bindings inside pattern default immutable» (правило 1 выше) была ДЕКЛАРАЦИЕЙ без энфорса на cross-binding — паттерн-биндинги (match arm / if Some(x) =) не были заведены в L1 launder-таблицу (D246 §ORACLE G), так что Ok(b0) => { mut b = b0 } на кучевом payload отмывало ro-заморозку МОЛЧА. Чекер теперь заводит bare pattern-bind = L1-ro (ту же launder-проверку, что явный ro x = ...), mut x внутри паттерна = mut — см. D246 §ORACLE G AMEND ниже.

Что

Синтаксис if pattern = expr { ... } и while pattern = expr { ... } — pattern matching прямо в условии с локальным binding в scope блока. Guard-условие через && (Plan 106, D34 amend 2026-06-17).

Pattern grammar унифицирована с match-arm patterns: те же правила (mut inside Some(mut x), bare = immutable) работают в обеих позициях.

Правило

// Constructor / destructure pattern — bare bindings default immutable
if Some(user) = cache.get(key) { process(user) }
if Some(mut buf) = pool.try_take() { buf.fill(0) }    // mut inside pattern
if (a, b) = pair { use(a, b) }
if { name, age } = user_opt { greet(name, age) }

while Some(item) = queue.pop() { handle(item) }
while Some(mut line) = reader.read_line() { line.trim_in_place() }

// Identifier pattern — REQUIRES `ro` or `mut` (footgun protection)
if ro user = compute_user() { use(user) }              // ✓ explicit ro
if mut counter = init() { counter += 1; … }            // ✓ explicit mut
if user = compute_user() { ... }                       // ✗ E_AMBIGUOUS_IDENT_PATTERN

// Guard через && (Plan 106, D34 amend 2026-06-17)
if Some(x) = cache.get(key) && x > 5 { use(x) }
if ro Some(user) = db.find(id) && user.is_active { process(user) }
while Some(item) = queue.pop() && item.valid { handle(item) }

// else-if
if Some(a) = lookup_a() {
    use(a)
} else if Some(b) = lookup_b() {
    use(b)               // a НЕ доступна
}

Правила:

1. Constructor / destructure pattern — bare bindings inside pattern default immutable. mut explicit когда нужно (Some(mut x), (mut a, b)). Consistent с match arms.
2. Identifier pattern (if NAME = expr) — обязательно ro или mut. Иначе E_AMBIGUOUS_IDENT_PATTERN (footgun protection: bare if x = compute() визуально неотличимо от assignment).
3. consume запрещён в conditions — E_CONSUME_IN_CONDITION.
4. Outer mut удалён — if mut Some(x) → use if Some(mut x) (mut moves inside pattern). Единое правило с match.
5. Guard-выражение: после scrutinee допустимо && + bool-expr; биндинги паттерна видны в guard. Аналог Rust let-chains (RFC 2497), выбрано && вместо запятой (Swift) за очевидность семантики и знакомость Rust-аудитории.
6. else if — корректно для всех форм.

Грамматика:

if-expr    := "if" if-cond block ("else" (if-expr | block))?
while-expr := "while" if-cond block
if-cond    := cond-pattern "=" expr ("&&" expr)?  // guard: && expr после scrutinee
            | expr
cond-pattern := ("ro" | "mut") IDENT type_opt
              | constructor-pattern         // Some(...) / None / etc.
              | tuple-pattern               // (a, b)
              | record-pattern              // { name, age }

Скоуп: связанные имена доступны в guard-выражении и в теле блока.

? работает: if Some(user) = Db.find(id)? { ... } пробрасывает ошибку наверх; внутрь блока заходим только при успехе.

Почему

1. «Получить и использовать если есть» без полного match-блока.
2. Unified grammar с match arms — единое правило (Some(mut x)), а не два разных (Rust if let Some(mut x) vs match Some(mut x)).
3. Footgun protection — identifier-pattern требует keyword’а (Plan 114 D184 §«identifier-pattern protection»).
4. Условные циклы — итерация пока паттерн совпадает.
5. Guard && — «получить и проверить» без вложенного if.

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

• Go-стиль ;-разделитель — нарушает D17 «один разделитель — запятая».
• := оператор — shadowing-проблемы Go.
• Smart-cast (Kotlin) — магия в типе, AI-first против.
• if let (Rust-style outer let) — Plan 114 retracted в пользу unified pattern grammar с match arms.
• Outer mut в pattern position (if mut Some(x)) — Plan 114 retracted; mut goes inside pattern (if Some(mut x)).
• Запятая-chain (Swift-стиль) — отвергнута в пользу && (Plan 106); amend 2026-06-17: добавлен && guard; запятая-chain отвергнута.

Связь

• D33 — ro/mut binding mutability.
• D184 — master keyword refresh (Plan 114).
• 02-types.md → D17 — pattern matching в match (shared grammar).
• Plan 106 — chain syntax.

D35. Методы инстанса через @, self отменён

Что

Методы инстанса объявляются как fn Type @method(...) с неявным self. Поля self — через @field. Мутирующий метод — fn Type mut @method(...). Конструкторы и static — через точку fn Type.name(...). Ключевое слово self отменено.

Правило

type Account {
    ro owner str
    _balance money
}

// конструктор / static — через точку, без @
fn Account.new(owner str) -> Account =>
    Account { _balance: 0, owner }

// метод инстанса — через пробел и @, неявный self
fn Account @balance() -> money => @_balance
fn Account @summary() -> str => "${@owner}: ${@_balance}"

// мутирующий — mut перед @name
fn Account mut @deposit(amount money) =>
    @_balance += amount

Грамматика:

free-fn          := identifier "(" params ")" effects? ("->" type)? "=>" body
static-method    := Type "." identifier "(" params ")" ...
instance-method  := Type ("mut")? "@" identifier "(" params ")" ...

После имени типа: . → static, @ или mut @ → instance.

Receiver — любой тип, включая примитивы

Receiver-тип может быть любым именованным типом: record, sum, newtype, unit-тип, protocol — и встроенный примитив (int, str, bool, f64, u8, …). Это естественное следствие того, что в Nova примитивы — обычные типы (D30, D32), просто с lowercase-именами и особым представлением в runtime.

// Static method on a primitive — `str` is a regular type.
fn str.from(i int) -> Self => /* ... */

// Instance method on a primitive — used via `value.method()`.
fn int @to_hex() -> str => /* ... */
fn f64 @round() -> int => /* ... */

ro s = str.from(42)            // static via D35
ro h = (255).to_hex()          // instance, parens around literal
ro r = 3.7.round()             // chained on numeric literal

Применение: From[X] для str (D73) — основной механизм строковой конверсии. Также int.parse(s str), bool.from(n int) и другие фабрики, не требующие отдельного wrapper-типа.

Ограничения: примитивы — закрытые типы, программист не может добавить новые поля (нет type str { ... } для существующего str). Только методы. Это согласовано с тем, что extension functions в Nova не вводятся (D46): метод определяется один раз в модуле, владеющем типом-receiver. Для примитивов это stdlib: fn int.method определяется только в stdlib-модулях, пользовательский код может определять методы только на собственных типах.

В теле метода @field — единственная форма доступа к self-полю. @.field невалидно. @ без поля — значение текущего инстанса (аналог self):

fn Account @copy() -> Account => @
fn Account @send(ch Channel[Account]) => ch.send(@)

Вызов методов — скобки обязательны:

ro acc = Account.new("alice")
acc.deposit(100)
ro bal = acc.balance()         // getter, обязательные ()

Unbound method value и lambda (bound method value удалён в Plan 132):

// Unbound: fn-pointer, self передаётся явно.
ro g = Account.@balance         // unbound: fn(Account) -> money
ro v = g(acc)                   // 100

// Closure захватывает receiver — замена bound-форме.
ro f = || acc.balance()         // lambda: fn() -> money
ro v2 = f()                     // 100

Правило @name в теле метода: @name без () = поле name; @name() = вызов метода name (включая cross-method вызов: @len() из @call_len() корректно эмитирует Nova_T_method_len(nova_self, ...)). Поле и метод с одним именем на одном типе — легально (нет коллизии).

REMOVED (Plan 132, 2026-06-09): obj.@method (bound method value). Замена: лямбда || obj.method() или unbound Type.@method.

Generic’и: [T] после имени типа (fn Vec[T] @len()) и/или после @name (fn Vec[T] @map[U](f T -> U)).

Почему

1. Минимум строк. fn Account.deposit(mut self, ...) → fn Account mut @deposit(...) экономит 6-9 символов на метод.
2. Один смысл @ — «принадлежит self». В сигнатуре @method, в теле @field.
3. Чёткое разделение. Точка = static (Account.new), @ = instance. Программист и LLM видят роль из синтаксиса.
4. Скобки обязательны — acc.balance() явно вызов, не поле. Property-механизмы (C#/Kotlin) делают это невидимым.

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

• fn Type.method(self, ...) — повторяющийся self в каждом методе и каждом обращении к полю.
• Property (property balance { get; set }) — невидимое «поле или вызов?»; известный источник путаницы в C#.
• @ как параметр (fn deposit(mut @, ...)) — @ приобретает два смысла.
• fn mut @Type.method — mut на типе vs на binding’е, разные смыслы.
• fn Type new(...) без точки — расходится с namespace path.

Связь

• D32 (если есть) / 05-memory.md — mut семантика mutable-binding’а.
• D37 — @field / @N для self.
• D38 — generic на типе и методе.
• D46 — operator overloading через @-методы.
• 01-philosophy.md → D1 — методы как часть парадигмы protocols + data.

Перегрузка методов

Полная семантика перегрузки методов (по типу аргумента, arity, mangling, bootstrap-status, ambiguity, disambiguation) — в D84. Здесь лишь напоминание: метод может быть перегружен несколькими сигнатурами на одном receiver-типе, резолв выполняется по статическим типам аргументов.

Method values (Plan 11 Ф.4)

Методы — first-class values: можно сохранить в переменную, передать в HOF, вернуть из функции. Три формы:

type Account { balance int }
fn Account.new(b int) -> Self => Self { balance: b }
fn Account @get() -> int => @balance
fn Account @add(n int) -> int => @balance + n

ro acc = Account.new(42)

// 1. Closure capturing receiver (replaces bound method value removed in Plan 132).
ro f = || acc.get()                     // тип: fn() -> int
ro g = fn(n int) -> int => acc.add(n)  // тип: fn(int) -> int
ro v = f()               // 42
ro r = g(10)             // 52

// 2. Unbound method value: self передаётся явно как первый аргумент.
//    Тип: fn(Receiver, <params>) -> R
ro h = Account.@add      // тип: fn(Account, int) -> int
ro r2 = h(acc, 10)       // 52

// 3. Static method value: обычная свободная функция.
//    Тип: fn(<params>) -> R
ro mk = Account.new      // тип: fn(int) -> Self
ro acc2 = mk(7)

Семантика

• Lambda capturing receiver — lambda closes over the receiver variable. Subsequent calls use the captured variable.
• Unbound — fn pointer без env’а. Caller обязан передать receiver как первый аргумент.
• Static — fn pointer без receiver’а вообще.

Использование в HOF

ro nums = [1, 2, 3]
ro negated = nums.map(int.@neg)          // unbound: применяет @neg к каждому
ro total = nums.fold(0, |n| acc.add(n))  // closure-light: добавляет каждый num к acc

Disambiguation для overloaded methods

Если у метода несколько overload’ов, используется lambda с явными типами аргументов:

fn Buffer mut @write(s str) -> ()
fn Buffer mut @write(b []u8) -> ()

ro buf = Buffer.new()
ro f1 = fn(s str) -> () => buf.write(s)      // выбор по типу аргумента
ro f2 = fn(b []u8) -> () => buf.write(b)

Тип аргумента в lambda однозначно определяет overload.

C-runtime представление

Lambda (closure) и unbound — оба используют generic NovaClosBase layout:

typedef struct { void* fn; void* env; } NovaClosBase;

fn указывает на сгенерированный wrapper, env — указатель на struct с captured receiver (для lambda) или dummy struct (для unbound). Call-site: cast fn к нужной сигнатуре, передача env + args.

Static method values — bare fn pointer (без env’а) — но в bootstrap для единообразия тоже оборачиваются в NovaClosBase.

Note: Bound method value (obj.@method) removed in Plan 132. Lambda || obj.method() is the explicit replacement.

Self в expression position (D66 расширение, Plan 11 Ф.4.5)

Self ранее работал только в type position (return type, parameter type). Plan 11 Ф.4.5 добавляет expression position:

type Account { balance int }

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

fn Account.new() -> Self =>
    Self.with_initial(0)                      // call current type's static

Резолюция: Self в expression context резолвится в имя текущего receiver-типа из метода (тот же current_receiver_type что для type-position). Полезно для default → parameterized constructor chain’ов и DRY.

Прецеденты: Rust impl Foo { fn make() -> Self { Self::new(2) } }, Swift Self.method(). D66 расширяется этим Plan’ом 11.

D37. Доступ к полям: .name для record, .N для позиционных и кортежей

Что

Доступ к полю / элементу — через точку:

• obj.name — поле record по имени;
• obj.0, obj.1 — поле позиционной структуры или кортежа по индексу (0-based);
• @name, @0, @1 — то же внутри методов инстанса для self.

Правило

// record — доступ по имени
ro u = User { id: 1, name: "alice" }
println(u.name)

// позиционная структура — по индексу
type Point(f64, f64)
ro p = Point(1.0, 2.0)
println(p.0)             // 1.0
println(p.1)             // 2.0

// кортежи — то же
ro pair = (1, "alice")
println(pair.0)
println(pair.1)

Внутри методов:

fn Point @magnitude() -> f64 =>
    math.sqrt(@0 * @0 + @1 * @1)

fn Account @summary() -> str =>
    "${@owner}: ${@balance}"

Mutation работает по правилам 05-memory.md (mut binding + поле без ro):

mut p = Point(1.0, 2.0)
p.0 = 5.0                // ок

Pattern matching как альтернатива:

match p {
    Point(x, y) => x + y
}
ro Point(x, y) = p      // деструктуризация

Парсер: .N после идентификатора или ) — field access. После числового литерала точка — только decimal. 1.foo — ошибка.

Почему

1. Точечный доступ для одного поля без полной деструктуризации.
2. .0/.1 — стандарт Rust/Swift, AI-friendly.
3. Compile-time проверка границ (в отличие от runtime obj[i]).

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

• Только pattern matching — многословно для простого доступа.
• Аксессоры (fst/snd) — не масштабируются для 3+ кортежей.
• obj[0] (TS array-style) — конфликт с runtime-индексацией массивов.

Связь

• 02-types.md → D17 — позиционные структуры (type Point(f64, f64)) объявляются через ().
• D35 — @name / @N внутри методов.

D38. Создание массивов и turbofish для дженериков

Что

Пустые массивы — литералом с annotation или static-методом на типе массива ([]T.with_capacity(n)). Когда inference не справляется — turbofish через те же [T] после имени, без Rust’овского ::.

Правило

Создание массивов:

// 1) литерал + annotation
mut buckets []Slot[K, V] = []
ro xs []int = [1, 2, 3]

// 2) inference из контекста
fn first(xs []int) -> Option[int] => ...
ro result = first([])           // [] выводится из аргумента

// 3) static-методы
ro buckets = []Slot[K, V].with_capacity(cap)
ro empty = []int.new()
ro zeros = []u8.filled(0, 1024)

Turbofish — те же [T], без :::

fn parse[T](s str) -> Result[T, ParseError] => ...
ro n = parse[int]("42")?            // в Result-возвращающей функции

ro c = Cache[str, int].new()
ro buckets = []Slot[K, V].with_capacity(16)
ro result = m.@get[int]("key")

Грамматика — generic-application:

generic-application := identifier "[" type ("," type)* "]"

Работает для функций, static-методов, конструкторов, instance-методов.

Почему

1. Парсер однозначен (D16) — :: не нужен. Rust сами признают ::<> ошибкой дизайна.
2. Static-методы на типе массива — тип явный, pre-allocation доступна.
3. Один синтаксис [T] — везде, без специальных операторов.

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

• Rust ::<T> — нужен только из-за <T>-ambiguity, у Nova её нет.

• Глобальный make[T](n) (Go) — не вписывается.

• Vec[T].new() — []T это встроенный синтаксис, не отдельный тип Vec. ОТКАЗ СНЯТ АМЕНДМЕНТОМ 2026-08-30 (реестр №840): он был вытеснен двумя ACTIVE-блоками и никто этого не записал. D239 (ACTIVE, Plan 138, 2026-06-10) объявляет []T СИНТАКСИЧЕСКИМ ПСЕВДОНИМОМ Vec[T] — то есть посылка этого отказа («не отдельный тип Vec») перестала быть верной; D232 (ACTIVE) даёт Vec[T].new() первой строкой таблицы Construction. Компилятор согласен с ними, а не с этим отказом: Vec[int].new() собирается и работает (замер сборкой и запуском 2026-08-30).

  Почему это записано, а не подправлено молча. Отвергнутое, ставшее нормой, — худший вид расхождения: читатель D38 находит запрет, читатель D232 находит канон, и оба правы по своему тексту. Нашло это окно 274 при подготовке волны и НЕ стало решать само, сославшись на порядок старшинства в AGENTS.md, — правильно: разрешение противоречия между источниками не его работа. Здесь оно разрешено не вкусом, а тем, что обе стороны (позднейшие ACTIVE-блоки и компилятор) уже говорят одно, а этот отказ остался единственным несогласным.

Связь

• D16 — generic через [T].
• D27 — []T как тип; static-методы на нём.
• D35 — Type.method для static.

Эволюция

D16 уточнён: [T] сам по себе не является типом — только generic-применение к именованной сущности.

Bootstrap (2026-05-07): turbofish реализован в codegen-парсере. Активируется в expression-position через peek-disambiguation: после Ident[T1, T2, ...] смотрим post-] token; если это ( (call), .IDENT( (method-call) или ? (Try) — это turbofish-узел (ExprKind::TurboFish { base, type_args }); иначе — обычный Index-доступ. Параллельно с этим, multi-arg внутри [...] — однозначно turbofish (Index не имеет comma). Bootstrap-codegen прозрачно делегирует TurboFish в base (monomorphization идёт по call-site / receiver-type), но AST сохраняет type_args для будущих этапов inference. Тесты — nova_tests/types/generics.nv.

Plan 98 (закрыт 2026-05-23): type-argument inference расширена на generic-параметризованные типы в позиции param. До Plan 98 infer_type_param_binding (emit_c.rs) выводил T только из голого T и []T — Option[T] / Result[T,E] / пользовательские Box[T]/HashMap[K,V] молча игнорировались → каждый generic-helper, принимающий generic-тип, требовал turbofish (check[int](a) вместо естественного check(a)). Хуже Rust/Go/TS, где это базовая unification. Plan 98 конвертировал функцию из associated fn в метод &self + добавил три рекурсивные ветки: Option[T] (recovery из NovaOpt_<sani> через novaopt_value_types), Result[T,E] (novares_ok_err), user-generic (через generic_type_instance_info). Граница (known limitation): []Option[T] / []Result[T,E] (массив generic-элементов) пока НЕ выводится — codegen эрейзит element type в receiver_type_c_ident (NovaArray_nova_int* для не-примитивов), теряя generic-инфу до inference; отдельный gap, не scope Plan 98. Тесты — nova_tests/plan98/.

Built-in API для []T (Plan 17 Ф.1, закрывает Q-array-api)

[]T — встроенный тип, не запись stdlib (Vec[T] нет). Граница между built-in API (компилятор знает напрямую) и stdlib extensions (методы добавлены через fn []T @method по D35) — зафиксирована ниже.

Built-in API — известно компилятору:

xs.cap() — присутствует, но не часть стабильного API для прикладного кода (detail of representation D32). Использование — для оптимизации pre-allocation; при изменениях representation может исчезнуть.

Field-access form (xs.len, xs.cap, xs.is_empty без скобок) — запрещена (D117). Compiler выдаёт E_SIZE_ACCESSOR_FIELD. Для bare .cap — diagnostic подсказывает append () (canonical form — .cap()).

Stdlib extensions (std/collections/vec.nv через D35) — то, что пишется как обычный пользовательский метод:

Расширяется по необходимости (contains, index_of, reverse, sort, zip, take, drop, unique, enumerate — добавляются по запросу use-case’ов; формальный D-block не нужен, любой fn []T @method валиден по D35).

Слайсинг xs[a..b] — реализовано Plan 96 (см. D144). Поддержаны 5 форм Range: a..b, a..=b, a.., ..b, .. (Rust RangeBounds parity). Возвращает sub-slice view (cap == len, push → realloc → silent detach). OOB → panic (D13).

Embed use []T — допустим по D39 (имя поля обязательно):

type Holder[T] {
    use data []T
    extra str
}
ro h = Holder[int] { data: [1, 2, 3], extra: "info" }
ro n = h.len()           // прокси к data.len() (D117 method-only)
h.push(42)                // прокси к data.push

Подробно — Plan 17 Ф.1, Q-array-api (closed), 02-types.md → D39 (use-delegation).

D40. Тело функции: => для одного выражения, {} для блока

Что

Два взаимоисключающих способа задать тело именованной функции: => expr (ровно одно выражение) или { stmt; ...; expr } (блок). Общий закон: => и {} не сочетаются. Распространяется на fn (named и closure-full), handler-method.

Closure-light (|x| body) — отдельная грамматика (D22): тело — bare expression ИЛИ block, без =>. D40 к ней не применяется.

Единственное исключение — match-arm (D19): arm может быть pattern => expr или pattern => { block } (Rust-стиль). Причина исключения — => гарантирован как маркер «начало результата» после pattern’а с возможным if-guard’ом, поэтому терять его в блок-форме нельзя.

Indentation не значим.

Правило

fn-decl       = 'fn' name '(' params ')' [effects] ['->' type] body
closure-full  = 'fn'      '(' params ')' [effects] ['->' type] body
body          = '=>' expression | block
block         = '{' { statement } [ expression ] '}'
closure-light = '|' params? '|' (expression | block)              // без =>
match-arm     = pattern [ guard ] '=>' ( expression | block )     // исключение

Везде, где есть => (named fn, closure-full, handler-method), после него идёт ровно одно выражение. Ни fn f() => { ... }, ни fn f() { => x }, ни fn(x) => { stmt; expr } — запрещены. Closure-light => вообще не использует.

Симметрия по контекстам:

Если нужно несколько statement’ов:

• для fn (named) и closure-full — блок-форма { stmt; ...; expr };
• для closure-light — block-форма прямо в |x| { stmt; expr } (D22);
• для match-arm — pattern => { stmt; expr } (D19);
• для handler-method — блок-форма без =>: op(p) { stmt; expr } (04-effects.md → D31).

// expression-body
fn double(x int) -> int => x * 2
fn HashMap[K, V].new() -> HashMap[K, V] =>
    HashMap[K, V].with_capacity(16)        // одно выражение, перенесённое

// block-body
fn next_pow2(n int) -> int {
    if n <= 1 { return 1 }
    mut p = 1
    while p < n { p *= 2 }
    p
}

Многострочный match/if — это одно выражение, поэтому => match {...} и => if {...} else {...} остаются легальными:

fn classify(n int) -> str => match n {
    0           => "zero"
    n if n > 0  => "positive"
    _           => "negative"
}
fn abs(x int) -> int => if x < 0 { -x } else { x }

Граница: появилось ли что-то кроме самого выражения (statement, let, return, for, while)? Тогда нужен { block }.

// НЕ ОК — `let` это statement, `=>` ожидает одно выражение
fn area(r f64) -> f64 =>
    ro pi = 3.14
    pi * r * r

// ОК — блок-форма
fn area(r f64) -> f64 {
    ro pi = 3.14
    pi * r * r
}

Почему

• Один общий закон. => означает «ровно одно выражение после» для лямбд, тела fn, handler-method. Match-arm — единственное исключение, оправданное необходимостью гарантированного маркера «начало результата» после pattern’а с возможным if-guard’ом (D19).
• Indentation-significant грамматика ломает copy-paste, плохо переживает auto-format (Python-стиль отвергнут).
• Парсер сложнее при значимых отступах.
• AI-инструменты часто переформатируют код — невидимая разница становится багом.
• Явные {} — ноль двусмысленности для форматера, линтера, LSP.
• Граница fn vs лямбда видна по форме. Блок-тело может иметь только fn name(...) { ... }, trailing-block и handler-method. Лямбда — никогда.

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

• => indented-block (F#/OCaml/Python-стиль) — indentation-significant.
• Только {} для всех тел — теряется компактная expression-body.
• {} после => (Kotlin/JS-стиль (x) => { ... }) — два маркера для одного, размывает границу «выражение vs блок».
• Сочетание => и {} для лямбд при запрете для fn — непоследовательно: общий закон должен работать одинаково для всех «безымянных» и «именованных» функций. Match-arm имеет особую природу (всегда требует => как маркер) и потому делает исключение.

Связь

• D22 — closure-light |x| имеет отдельную грамматику (bare expr или block, без =>); closure-full fn(...) подчиняется D40 как named fn.
• D19 — match-arm: pattern => expr или pattern => { block } (единственное исключение из правила «=> и {} не сочетаются»).
• D23 — guard-clauses через return требуют блок-формы.
• D43 — trailing-block (без params) — f(args) { block }; trailing-fn (с params) — f(args) fn(p) body.
• 04-effects.md → D31 — handler-method имеет две формы (=> expr или { block }), как fn.
• D45 — inference работает только на expression-body.
• D49 — {} правит newline-разделители.

Эволюция

Ревизия (2026-05-10): правило «=> и {} не сочетаются» больше не применяется к closure-light (|x|), у которой своя грамматика без =>. Изначально правило покрывало «лямбды» как единый класс; после перехода на two-level closure (D22) «лямбды» расщепились на closure-light (отдельная грамматика) и closure-full (fn(...), подчиняется D40 как named fn).

D43. Trailing: { block } без params, fn(p) body с params

Что

Если последний параметр функции — функционального типа, аргумент-функция может быть вынесен за () вызова в одну из двух форм:

• trailing-block — f(args) { block } — для callback’ов без параметров (DSL-форма: with_timeout, retry, transaction).
• trailing-fn — f(args) fn(params) body — для callback’ов с параметрами. Синтаксис идентичен closure-full (D22) без имени.

Скобки () вызова всегда обязательны; trailing-форма должна начинаться на той же строке, что ).

|...| (closure-light) в trailing-position запрещён — для callback’ов с params используется fn(...), иначе ambiguity с binary |. Closure-light с параметрами передаётся через args: f(|x| body).

Правило

// trailing-block — без параметров (DSL)
with_timeout(2.seconds) {
    Db.exec(sql`UPDATE counters SET v = v + 1`)
}

retry(3) {
    Net.get(url)
}

transaction(db) { ... }

// trailing-fn — с параметрами; обе формы тела
list.filter() fn(x) => x > 0                            // expr-body
list.fold(0) fn(acc, x) { acc + x }                      // block-body
list.map() fn(s str) Fail -> int { parse(s)? }           // typed + effects

// closure-light — в args, не в trailing
list.filter(|x| x > 0)
list.fold(0, |acc, x| acc + x)

Грамматика:

call           = primary '(' args ')' [ trailing ]
trailing       = trailing-block | trailing-fn
trailing-block = '{' block-body '}'
trailing-fn    = 'fn' '(' params ')' [ effects ] [ '->' type ] body
body           = '=>' expression | block
block-body     = { statement } [ expression ]

Trailing-fn идентична closure-full (D22). Параметры пишутся как у named fn — (x int, y int), типы опциональны если выводятся из ожидаемой сигнатуры callee.

Правила:

1. () обязательны — trailing должен следовать сразу после ).
2. На той же строке — для trailing-block { сразу после ); для trailing-fn fn сразу после ). Перенос строки между ними запрещён.
3. Тип последнего параметра — функциональный. Иначе type error.
4. Один trailing на вызов.
5. |...| (closure-light) в trailing-position запрещён — пишется fn(...) или передаётся через args вызова.
6. Trailing-block — без параметров. Если callback требует параметры — использовать trailing-fn (fn(p) ...) или закрытие в args.
7. Implicit it запрещён — параметр всегда именован.
8. Method chain — те же правила: list.filter() fn(x) => x > 0.

spawn — исключение. spawn — keyword-конструкция, не вызов функции, поэтому не подчиняется D43. Его синтаксис: spawn expr, где expr — любое выражение: вызов функции (spawn foo()), блок (spawn { body }), и т.д. spawn() { body } — запрещено (пустые скобки без смысла вводят в заблуждение).

Дисамбигуация с record-литералом:

ro u = User { name: "alice" }                  // record (имя типа, без ())
fn_call(arg) { name: "alice" }                  // trailing-block (после `)`)
fn_call(arg) fn(x) => x.value                    // trailing-fn
fn_call(arg, User { name: "a" })                // record внутри args

Многие language primitives становятся обычными функциями stdlib:

fn with_timeout[T](dur Duration, body fn() -> T) Fail -> T
fn transaction[T](mut db Db, body fn() Db Fail -> T) Db Fail -> T
fn retry[T](attempts int, body fn() Fail -> T) Fail -> T

Keyword-блоки остаются (без ()): with X = h { ... }, parallel for x in xs { ... }, region { ... }, match/if/for/while. Различие с trailing — наличие ().

Почему

1. () обязательны — локальный парсер без type-directed parsing. Kotlin/Swift вынуждены смотреть на тип, чтобы различить trailing и record-литерал.
2. trailing-fn = closure-full без имени. Симметрия — программист учит одну грамматику параметров. Парсер коммитится за fn-keyword после ), никаких ambiguity.
3. Closure-light не в trailing. func() |x| body создавал ambiguity с binary | в expression-position. Запрет даёт парсеру мгновенный ответ: |...| → closure-light в args; fn(...) после ) → trailing-fn; {...} после ) → trailing-block.
4. Trailing-block — DSL-ниша. Для with_timeout/retry/transaction нет параметров callback’а, и { block } визуально маркирует «здесь начинается тело DSL’а».
5. Не closure-литерал внутри (). Closure-light с params передаётся через args (f(|x| ...)), trailing — для последнего функционального параметра. Программист выбирает по форме (длина тела, наличие let’ов).

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

• Опциональные () (Kotlin) — нет локального способа развести с record-литералами.
• () опционально в method chain — лишнее исключение.
• Implicit it — нелокальный reasoning.
• do { body } keyword — лишнее ключевое слово.
• Indentation-significant — конфликт с D40.
• Trailing-block = лямбда (до 2026-05) — переклассифицировано в самостоятельную грамматику.
• Trailing-block с параметрами через { x => body } (до 2026-05-10) — заменено на trailing-fn (fn(x) ...) для симметрии с closure-full.
• Trailing closure через |x| — func(args) |x| body создавал ambiguity с binary | в expression-position; fn(...) решает за один токен.

Связь

• D22 — closure-light в args через |x|; trailing-fn идентична closure-full без имени.
• D40 — trailing-fn body подчиняется правилу => ↔ {} как named fn; trailing-block — block-only (без =>).
• 04-effects.md — handler-блоки with X = h { ... } — keyword-блок, не trailing.
• 06-concurrency.md — parallel for, supervised, race, select — keyword-блоки.

Эволюция

Ревизия (2026-05): переименование «trailing-lambda» → «trailing-block». Раньше форма f(args) { params => body } называлась лямбдой и конфликтовала с правилом «лямбда = одно выражение». Тогда же переклассифицировано в самостоятельную грамматику.

Ревизия (2026-05-10): trailing расщеплён на trailing-block (без params, для DSL) и trailing-fn (с params, через fn(...)). Старая форма f(args) { x => body } отменена. Триггер — переход closure на two-level (|x| + fn(...), D22); старая форма с => внутри {} после ) создавала путаницу с новым правилом «=> не используется в closure-light». Симметрия trailing-fn ↔ closure-full даёт парсеру и программисту одно правило вместо двух. Migration: ~10 примеров trailing с params в spec/.

D44. Числовые литералы

Что

Полный набор числовых форм; _ как разделитель между цифрами; default — int для целых, f64 для дробных. Type-suffixes (100u32, 1.5f32) отвергнуты — type через annotation или as-cast.

Правило

// целые: десятичные / hex / binary / octal
1
1_000_000_000
0xFF             0xFF_FF_FF_FF
0b1010_0001
0o755

// float
1.5              1_234.567_89
1e10             1.5e-3            1_000.5e6

// type через cast или аннотацию
ro x i32 = 100
100 as u8
0xFF as u32

Default-типы: int (= i64 на bootstrap per D129; future-arch may become platform-pointer-width signed) для целого, f64 для дробного. Контекст (annotation, тип параметра, тип поля) переопределяет с hard compile-time range-check (см. D227 для range-policy, no narrow-fallback, negative-в-unsigned правил):

ro x u8 = 200             // 200 это u8
fn write(b u8) -> () => ...
write(0xFF)                // 0xFF это u8
ro arr []f32 = [1.0, 2.0]            // annotation-контекст: литералы → f32
ro v = Vec[f32].from([1.0, 2.0])     // param-тип `from(arr []f32)` → литералы → f32
ro w = Vec[f32].of(1.0, 2.0)         // вариадик `of(...args []f32)` → то же

Impl-note (Plan 154.1, 2026-06-14): приведение числового литерала к элементному float-типу из контекста для array-литералов ([]f32/Vec[f32]) было codegen-дырой — литералы строили []f64, чьи биты реинтерпретировались как f32 → мусор. Исправлено: try_emit_typed_vec_literal берёт float-hint когда ВСЕ элементы — числовые литералы (FloatLit/IntLit); turbofish-static арг-array- литерал эмитится с param-C-типом. Гард: только всё-литеральные массивы. Переменная f64 в []f32-контексте (Vec[f32].from([f64_var])) — НЕ сужается молча: это неявное сужение f64→f32, запрещённое для не-литералов (как as-cast narrowing, D54) → громкая ошибка E_ARRAY_ELEM_NARROW (нужен явный as f32 на элементе). Маркер [M-154.1-f32-literal-coercion] ✅ (pos+neg тесты plan154_1).

Разделитель _ — только между цифрами. Запрещено: в начале (_1), в конце (1_), подряд (1__0), сразу после префикса (0x_FF), вокруг точки (1_.5), вокруг e (1_e10).

Regex:

decimal-int = [0-9] (_? [0-9])*
hex-int     = "0x" [0-9a-fA-F] (_? [0-9a-fA-F])*
binary-int  = "0b" [01] (_? [01])*
octal-int   = "0o" [0-7] (_? [0-7])*
float       = decimal-int "." decimal-int (("e"|"E") ("+"|"-")? decimal-int)?
            | decimal-int ("e"|"E") ("+"|"-")? decimal-int

Почему

1. Без suffixes — меньше шума. 100u32, 0xFFu8, 1.5f32 хуже 100 as u32. let x u32 = 100 уже работает через inference.
2. Тренд новых языков (Swift, Go, Zig) — без суффиксов.
3. AI-friendly — меньше форм записи.
4. int платформенно — компромисс между Rust (фиксированный) и Python (bigint).
5. _ строгий regex запрещает мусор (1__0, _1).

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

• Type-suffixes (100u32, 1.5f32) — шум, дублирование с annotation, прецедент новых языков против.
• Свободные _ — хочется без 1__0 и _1.
• ' как разделитель (C++14) — экзотический выбор, _ стандарт.

Связь

• D27 — литералы длин массивов берут тип int.
• D33 — литералы в const.
• D40 — литералы в expression-body.

Строковые литералы и интерполяция ${expr}

Строковый литерал "..." хранит UTF-8 байты (тип str). Внутри литерала разрешена интерполяция через ${expr} (D-string-interp, закрыт в Plan 17 Ф.1):

ro name = "alice"
ro age  = 30
ro s = "Hello, ${name}, you are ${age}"   // → "Hello, alice, you are 30"

Семантика — sugar над + и str.from(...) (D73 [Into]). Литерал с N интерполяциями развёртывается в N+1 литеральных частей и N выражений:

"a${x}b${y}c"
// = "a" + str.from(x) + "b" + str.from(y) + "c"

Каждое выражение ${expr} должно иметь тип, удовлетворяющий Into[str] (через D73 это автоматически верно для int, f64, bool, str, char, Option[T] где T: Into[str], и любых user-типов с реализованным From[Self] for str или Into[str]).

Escape для буквального ${ — обратный слэш: "price: \${value}" печатает ${value} без интерполяции.

Multi-line.

Амендмент (владелец, 2026-08-29): сырой newline внутри "..." РЕТРАКТИРОВАН — решение «принимаем исследования», по 2026-08-29-string-literals-proposal.md, нормативно оформлено в D467 §4. До этой даты абзац разрешал «сырой newline между "..."», и оракул этому следовал. Причина ретракции — диагностика: при разрешённом сыром переносе забытая закрывающая кавычка молча съедает следующие строки, и ошибка указывает в место, не имеющее отношения к опечатке. Hard error E_STR_RAW_NEWLINE. Сообщение называет обе замены. Канон. Длинный текст без переводов строк — продолжение строки \ перед переносом (D467 §3). Настоящий многострочный текст — backtick (D467 §5–§7). \n внутри литерала работает как работал.

Пустое выражение "${}" — compile error.

// Что разрешено
ro v = "x = ${1 + 2}"             // sub-expression — ok
ro v = "user = ${user.name()}"    // method call — ok
ro v = "${a}${b}"                 // соседние интерполяции — ok
ro v = "literal \${name}"         // escape — буквальное "${name}"

// Что НЕ работает
ro v = "${}"                      // ✗ пустое выражение
ro v = "${ro x = 1; x}"          // ✗ statement, не выражение

Bootstrap status (2026-05-08): ✅ реализовано в lexer/parser/codegen (Plan 17 Ф.4):

• Lexer видит \$ как escape — сохраняет sentinel-байт \x01$ (SOH+$), чтобы парсер мог отличить literal-${ от interpolation-${.
• Parser разворачивает TokenKind::Str(s) в expression-position в ExprKind::InterpolatedStr { parts: Vec<InterpStrPart> }. Каждое ${expr} парсится через sub-Lexer + sub-Parser; balanced {} внутри expr поддерживается. Пустое ${} — compile error.
• Codegen эмитит цепочку StringBuilder с pre-size estimate: Nova_StringBuilder_static_with_capacity(N) → Nova_StringBuilder_method_append_str(...) per fragment → Nova_StringBuilder_method_into(sb). Одна аллокация на итоговый buffer; нет O(N²) от цепочки +. Per-fragment dispatch по типу: nova_str pass-through, nova_bool → nova_bool_to_str, nova_f64 → nova_f64_to_str, CharLit → nova_char_to_str (UTF-8 encode), user-тип с @into() -> str (D73) — Nova_T_method_into, fallback nova_int_to_str.
• Interp (для тестов и nova run) — обычная конкатенация через format!("{}", value).
• Const-инициализатор: интерполяция запрещена (требует runtime StringBuilder); compile error «not allowed in const initialiser».

Тесты — nova_tests/types/string_interpolation.nv (13 тестов, все PASS): int / negative int / str / bool / f64 / char-литерал / multi-interpolation / expression в ${} / escape \${ / большие строки через StringBuilder.

В tag\…`-литералах ([D48](#)) tag-функция получает части и аргументы раздельно — для них интерполяция работает по той же грамматике ${expr}`, но обработка идёт user-функцией.

Связь: D48 (tagged templates — raw-строки tag\…`без интерполяции по такой же грамматике${expr}, но обработка зависит от tag-функции), [08-runtime.md → D73](/spec/decisions/runtime/#d73) (str.fromчерезFrom/Into), [08-runtime.md → D26](/spec/decisions/runtime/#d26) (str` тип

• конкатенация).

Format spec extension (Plan 91.14 D229)

${expr:SPEC} — Plan 91.14 D229 extension к base interp-string grammar. V1 supports :? (debug format via Debug.@debug). См. D229 для подробного описания + 3 новых error codes (E_FORMAT_SPEC_UNKNOWN / E_FORMAT_SPEC_EMPTY / E_FORMAT_SPEC_TRAILING). Future extensions (:hex, :pad-N, :.3) — [M-91.14-format-dsl-extensions] followup.

D44-амендмент (2026-07-25, Plan 102, реестр 221.1 №102): вложенные строки/кавычки внутри ${...} — легальны (PEP 701/JS-путь)

Проблема (было). Строковый сканер лексера был одномерным: искал первую неэкранированную ", НЕ отслеживая ${}-глубину. Разбиение на интерполяции (desugar_string_interpolation, parser/mod.rs) было постфактум-проходом поверх уже вырезанной строки, с наивным {/}-счётчиком (тоже string-неосведомлённым). Итог: "hello, ${req.param("name")}" и ТИПОВОЙ "${m["key"]}" (индекс, D238 @index) ловили «unterminated interpolation» или мусор — внутренняя " (внутри аргумента метода / индекс-ключа) закрывала ВНЕШНЮЮ строку раньше времени.

Норма (стало). ${...} — это Nova-выражение, а не строковое содержимое. Внутри него легально встречаются:

• вложенные строковые литералы, включая индекс со строковым ключом ("${m["key"]}") и метод со строковым аргументом ("${req.param("name")}") — БЕЗ экранирования внутренних кавычек;
• вложенная интерполяция внутри такой вложенной строки ("${f("x ${y} z")}"), рекурсивно, любой глубины;
• {/} record-литералов и блоков внутри выражения (${ if c { a } else { b } }).

Escape \${ (буквальный ${ без интерполяции) — без изменений. Пустое ${} — по-прежнему compile error.

Реализация. Единый string/brace-aware сканер scan_interpolation_body (compiler-codegen/src/lexer/mod.rs) — стек режимов (string-mode / expr-mode с brace-depth), находит истинную парную } для ${, проходя сквозь произвольно вложенные строки/скобки/интерполяции. Используется ДВАЖДЫ одним и тем же кодом (не два дубля):

1. Лексером (lex_string) — чтобы найти истинный конец строкового литерала, содержащего ${...} с вложенными строками (иначе внутренняя " обрывала бы строку раньше времени, старый баг). Диапазон ${...} копируется в токен СЫРЫМ (без escape-декодирования) — это Nova-исходник, а не строковое содержимое; его decode/re-lex делает шаг 2.
2. Парсером (desugar_string_interpolation) — для сплита уже вырезанной строки на литерал/expr-части (заменяет старый наивный {/}-счётчик).

Диагностика реально незакрытой интерполяции ("abc ${x — EOF без парной }) теперь ловится на лексер-уровне, с точным span’ом на ${, начавший интерполяцию: unterminated interpolation (started here): ... ${has no matching} before end of string/file.

Связь: база — этот же D44 (### Строковые литералы и интерполяция ${expr}), D238 (Index[K,V] — a[key] → a.@index(key)), D258 (формат-спек после : — не затронут этим амендментом). Позитивные фикстуры — spec_tests/conformance/interp_nested_strings.nv; негативная — spec_tests/conformance/neg/interp_unterminated_neg.nv. См. также docs/guide/strings.md.

D45. Inferred return type для expression-body

Что

В expression-body (=> expr) тип возврата -> T опционален — выводится из тела. В block-body ({ ... }) -> T обязателен, если тип не unit.

Правило

// expression-body — -> T опционален
fn double(x int) => x * 2                          // -> int выведен
fn Duration @as_nanos() => @nanos                  // -> i64 выведен
fn Duration @is_zero() => @nanos == 0              // -> bool выведен
fn HashMap[K, V] @len() => @count                  // -> int выведен

// block-body — -> T обязателен
fn next_pow2(n int) -> int {
    if n <= 1 { return 1 }
    mut p = 1
    while p < n { p *= 2 }
    p
}

fn process() {                                     // -> () можно опускать
    Log.info("hello")
}

Inference локальный (по одной функции, одному выражению), не Hindley-Milner:

• литерал → его тип; @field → тип поля;
• вызов → тип возврата вызываемого; record-литерал T { ... } → T;
• match/if-else → unification веток.

Style-guide:

• export функции — писать -> T явно (линтер предупреждает).
• Сложные match’и — писать явно.
• Generic-функции — связь параметра с возвратом полезно видеть.
• Простые геттеры/предикаты/конструкторы — опускать.

Почему

1. Compact form для тривиальных методов — getters, predicates.
2. Локальный inference — дёшев, прозрачен, не масштабирует на весь модуль.
3. Граница совпадает с D40 — где =>, там и inference; где {}, там типы обязательны.
4. Прецедент Kotlin.

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

• Inference в block-body — теряется явный контракт; диф большой функции мог бы молча менять тип возврата.
• Полный inference (Haskell) — public API теряет явный контракт.
• -> T обязателен везде — шум для тривиальных одностроек.

Связь

• D40 — граница применимости.
• D20 — -> () опускается всегда.
• 07-modules.md → D47 — export функции и линтер.

Реализация (Plan 55 Ф.3, 2026-05-16)

Bootstrap-codegen (compiler-codegen/src/codegen/emit_c.rs::return_type_c) реализует только Expr-body inference (FnBody::Expr) — Block-body без аннотации → nova_unit (как раньше; см. «Что отвергнуто» выше).

Inference при registration call-site signatures (free fn + method) делегируется в return_type_c. Это гарантирует что caller’ы видят правильный return type до emit_fn собственно body.

Edge-case: если body Expr возвращает void* или unknown — fallback на nova_unit (safety).

D46. Перегрузка операторов через @-методы

AMEND (решение владельца 2026-08-02, окно p-op-channel): @not RETRACTED — ! сужен до bool СТРОГО, больше не перегружаемый оператор.

!a БОЛЬШЕ НЕ диспетчится на пользовательский метод @not(). ! остаётся ЕДИНСТВЕННО логическим отрицанием на bool — !x, где x — не bool (числовой/строковый/пользовательский record/sum-тип), теперь ошибка чекера [E_UNARY_OPERAND_TYPE] («требуется bool»), а не dispatch-попытка на @not(). Селектор not убран из UNOP_TABLE (compiler-codegen/src/codegen/operator_dispatch.rs) и из D46-таблицы ниже.

Почему: @not был единственным унарным оператором, для которого «тип результата = тип операнда» — не тождество (Bool→UserType), и единственным, для которого не было НИ ОДНОГО реального потребителя в std/examples (грепом на момент решения: только 2 conformance-фикстуры, обе — carrier-тесты самого @not, не реальный код). Побитовое дополнение уже получило отдельный оператор (~/@bitnot, AMEND 2026-07-27 ниже) — по тому же прецеденту ! оставлен строго логическим, без второй перегружаемой роли. Устраняет асимметрию с &&/|| (никогда не перегружались, Правило 2) и снимает необходимость операторному чекер-каналу (план 196, окно p-op-channel) резолвить единственный унарный оператор БЕЗ обратного тождества типа.

Фикстуры-носители снесены (владелец подтвердил): бывшие spec_tests/conformance/d46_operator_overload_at_methods.nv (секция D46BoolBox/@not-тесты) и m128_neg_not_operator_only_pos.nv (M128Neg@not-DCE-репро) — обе существовали только ради @not. Негативная фикстура !x на не-bool — spec_tests/conformance/neg/.

AMEND (решение владельца 2026-07-27): побитовое семейство переименовано в bit-префикс + введён оператор ~.

(A) @and/@or/@xor → @bitand/@bitor/@bitxor (RETRACT прежних имён). В Nova &/| — ЧИСТО побитовые: логические &&/|| не перегружаются вовсе (Правило 2 ниже), поэтому имена and/or, читающиеся в прозе и в большинстве языков как ЛОГИЧЕСКИЕ, вводили в заблуждение. Эталон архитектуры — Rust — префиксует ровно ради этого различения (BitAnd::bitand, BitOr::bitor, BitXor::bitxor). Момент выбран по цене: реализаций прежних имён в std было ноль (первый потребитель — std/math/int128.nv), позже переименование стоило бы миграции.

(B) Введён ~a → @bitnot() — побитовое дополнение, ПЕРЕГРУЖАЕМОЕ (решение владельца: доступно и пользовательским типам, не только примитивам). До этого побитового НЕ не существовало КАК ОПЕРАТОРА: ! в Nova — логическое отрицание (на bool работает, на целых нет), а ~ отсутствовал. Единственным путём был ширино-зависимый обход x ^ 0xFFFF… — 9 сайтов в std (checksums/crc32.nv:74,103, crypto/md5.nv:196 — там прямо комментарий // ~B, то есть автор думает «~B», а пишет маску). Обход опасен: при смене ширины типа (u32→u64) маска МОЛЧА перестаёт быть дополнением, компилятор этого не ловит. ~x ширино-независим по построению.

Семантика ~ на знаковых — дополнение до двух: ~x == -(x + 1). Переполнения не бывает (trap неприменим). Приоритет — унарный, как ! и унарный -.

!a → @not() НЕ меняется и остаётся ЛОГИЧЕСКИМ — именно поэтому побитовому дополнению нужен собственный оператор, а не перегрузка ! (путь Rust, где ! служит обеим ролям, нам закрыт: ! уже логический). [RETRACTED 2026-08-02 — см. AMEND выше]: @not() как перегружаемая цель для ! впоследствии полностью убрана (! сужен до bool строго); в момент ЭТОГО амендмента (2026-07-27) @not ещё существовал, текст сохранён как историческая запись решения “не давать ~ роль !”.

Реализация — план 234 (компилятор: переименование диспетчера + парсер/лоуэринг ~; миграция 9 обход-сайтов). Маркер [M-bitwise-operator-method-naming].

Что

Стандартные операторы автоматически вызывают instance-методы с фиксированными именами. Если у типа есть метод нужного имени — оператор работает. Custom-операторы запрещены.

Правило

fn Duration @plus(other Duration) -> Duration =>
    Duration { nanos: @nanos + other.nanos }

fn Duration @times(n i64) -> Duration =>
    Duration { nanos: @nanos * n }

ro total = 1.hour() + 30.minutes()       // вызывает @plus
ro triple = 5.seconds() * 3              // вызывает @times

(C) Compound-присваивания &= |= ^= <<= >>= (решение владельца 2026-07-27, «мы просто забыли про них»): арифметические +=/-=/*=//= существовали, битовых не было. Семантика — десугар в a = a <op> b; отдельного операторного метода НЕТ: пользовательские типы диспетчеризуются теми же @bitand/@bitor/@bitxor/@shl/@shr. Реализация — план 234 Ф.2а.

(F) % определён и на ПЛАВАЮЩИХ (2026-08-17, реестр №707): 7.5 % 2.0 — законное выражение. Вопрос поставлен окном 274, обнаружившим расхождение: nova check принимал, nova build падал ошибкой clang «invalid operands to binary expression» — текст ЧУЖОГО компилятора утекал пользователю вместо диагностики Nova (в C оператор % определён только для целых). Почему законен, а не запрещён: таблица приоритетов перечисляет % без ограничения по типам; D46 даёт a % b -> @rem(b) перегружаемым, то есть операция мыслится общей; C (fmod) и Rust (% на float) её имеют, запрещает только Go. Запрет сузил бы язык ради обхода дефекта кодогена. Семантика — как у целых и как в C/Rust: знак остатка берётся от ДЕЛИМОГО (-7.5 % 2.0 == -1.5), а не евклидов. Лоуэринг: fmod для f64, fmodf для f32 (не fmod, иначе двойное округление); составная форма x %= y десугарится в x = fmod(x, y) — то же обещание, что (E) даёт для целых. Деления на ноль здесь НЕТ как ошибки: IEEE-754 даёт NaN, паника целых (D427) к плавающим не применяется — как и у /.

(E) Compound-присваивание %= (решение владельца 2026-08-16): последний оператор уровня 1 таблицы приоритетов, которого не было в языке. Найдено окном 274 при сверке novac с оракулом: из одиннадцати операторов строки «уровень 1» (= += -= *= /= %= &= |= ^= <<= >>=) десять принимались, а %= давал unexpected \=` in expression. **Это не был осознанный пропуск и не опечатка таблицы:** амендмент (C) выше добавлял битовое семейство со словами владельца «мы просто забыли про них» — и %=забыли в тот же раз, а D427 (2026-07-16) зафиксировал следствие как факт языка («в языке НЕТ%=, только Div-вариант AssignOp»), не заметив, что таблица приоритетов требует его. Таблица была права, язык — нет. Семантика — как у (C): десугар в a = a % b, отдельного операторного метода НЕТ, пользовательские типы идут тем же @rem. Guard достался бесплатно: D427 уже даёт nova__checked_remдля каждого членаIntsс тем же условием, чтоchecked_div (b == 0→ паника «division by zero»; signedMIN % -1→ «division overflow», потому что x86idivфолтит на overflow ЧАСТНОГО независимо от истинного остатка). Проверено наint, i64, u8, элементе вектора (v[i] %= k`) и на нуле (паника, не SIGFPE).

(D) ~ определён ТОЛЬКО для целочисленных (решение владельца 2026-07-27): ~true/~1.5/~"str" — ошибка чекера (на bool логическое отрицание — !); для пользовательских типов — через объявленный @bitnot(). Эмиссия на узких ширинах учитывает C integer promotion: беззнаковые узкие — x ^ MASK ширины (нулевое продвижение делает результат корректным без каста), знаковые узкие и все широкие — голый ~ (план 234, таблица эмиссии).

Mapping:

Правила:

1. Только методы инстанса — привязка к первому операнду.
2. &&, || не перегружаются — short-circuit предсказуем.
3. != выводится из @equal — отдельно объявлять не надо.
4. Custom-операторы запрещены (:+, >>= и т.п.) — фиксированный набор символов.
5. Никаких protocol/trait — структурное соответствие по имени. 5а. !a НЕ перегружается (RETRACTED 2026-08-02) — единственный невырожденный унарный оператор, оставленный строго встроенным на bool, тем же принципом, что Правило 2 для &&/||.
6. Type coercion нет — Duration + 30 ошибка, нужен Duration + 30.seconds().
7. Overloading методов по типу аргумента разрешён, если сигнатуры различимы:

fn Vector @times(s f64) -> Vector =>     // умножение на скаляр
    Vector { x: @x * s, y: @y * s }

fn Vector @times(other Vector) -> f64 => // dot product
    @x * other.x + @y * other.y

Примечание (Plan 91.8b, 2026-06-17): @eq/@lt/@le/@gt/@ge — УДАЛЕНЫ как operator-dispatch имена. Используй Equal.@equal / Compare.@compare. Подробнее: D363.

Амендмент (владелец, 2026-07-21): исключение для str — a + b запрещён. Строка | a + b | @plus(b) | свободный | таблицы выше перестаёт применяться к str++ конкретно: nova_str + nova_str — hard error E_STR_CONCAT_PLUS, а не dispatch на @plus. str определяет @plus (std/src/runtime/string/transform.nv, делегирует @concat), но операторный + больше не диспатчится на него ни для какого типа операнда — единственное такое исключение в языке. Канон — string-интерполяция ("${a}${b}") или явный .concat(...)/ StringBuilder в цикле. Подробности и мотивация — амендмент D216 §1 (str-блок, рядом с @concat/operator-lowering option (b)).

Почему

1. Просто и предсказуемо — структурное matching по имени, без trait-механики.
2. Закрытый набор операторов — Scala-style символьные методы (:+, <>) известны как источник нечитаемости.
3. &&/|| фиксированы — short-circuit семантика.
4. Прецедент Kotlin — фиксированные имена методов.

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

• Через protocol/trait (Rust impl Add, Swift) — избыточно.
• Custom-операторы (Scala/C++) — нечитаемый код.
• Свободные функции (fn plus(a, b)) для операторов — unification-ambiguity при резолве a + b. Overloading свободных функций по типам аргументов сам по себе разрешён (D84), но привязка операторов к receiver-методам (@plus/@times) однозначнее: компилятор знает, где искать реализацию.
• Перегрузка &&/|| — нарушает short-circuit.
• Auto-derive @equal/@compare — отдельный механизм, не часть D46 (см. D363).

Связь

• D35 — те же @-методы.
• D45 — методы операторов имеют inferred return при expression-body.
• 02-types.md — отсутствие trait/impl.

Эволюция

Закрывает Q16 (bitflags): type Permission(int) с @or/@and/@not для |/&/!.

D363. Operator dispatch via protocols — замена magic methods (Plan 91.8b)

Status: active (2026-06-17, Plan 91.8b).

Что

Операторы сравнения диспатчятся через протоколы:

Примитивы (int, bool, f64, char) — встроенный C-диспатч, без вызова метода.

Что удалено

@eq, @lt, @le, @gt, @ge как operator-dispatch имена — удалены из компилятора (Plan 91.8b).

Связь

• D46 — operator overloading base
• D109 — Equal/Compare протоколы
• Plan 91.8b

D48. Tagged template literals

Что

Литералы вида tag`raw_text` — синтаксический сахар над вызовом функции tag, получающей сегменты текста и интерполированные значения раздельно.

Правило

ro j = json`{"name": "alice"}`
ro q = sql`SELECT * FROM users WHERE id = ${user_id}`
ro h = html`<div>${escape(name)}</div>`
ro r = regex`\d{3}-\d{4}`
ro b = bytes`deadbeef`

Грамматика:

tagged-template = identifier '`' template-body '`'
template-body   = ( raw-char | escape-seq | interpolation )*
escape-seq      = '\\' ( '`' | '\\' | '$' )
interpolation   = '${' expression '}'

Амендмент 2026-08-30 (D467 §6, реестр №830). Здесь стояло '\\' ( '’ | ’\’ | ’${’ | ‘n’ | ‘t’ | … ) — набор с МНОГОТОЧИЕМ, и это неверно дважды. Во-первых, D467 §6 закрыл набор до РОВНО ТРЁХ (`` \ , `\\`, `\$`), а `\n`/`\t` из него убраны: backtick многострочный, перевод строки набирается клавишей, а раскрытие ломало пути ( C:\new\table “) и regex. Во-вторых, третий escape записан здесь как '${' — три символа, — тогда как реализация и D467 говорят \$: слеш экранирует ОДИН доллар, а { дальше идёт текстом.

Почему амендмент отдельной строкой, а не тихой правкой: 2026-08-29 D467 получил амендмент к разделу «Что отвергнуто» этого же блока (снятие «Implicit tag»), а ЭТОТ блок грамматики остался нетронутым — и сутки читатель D48 находил нормой одно, читатель D467 другое. Нашла это охота по оракулу (план 278 Ф.7), а не вычитка: агент честно отказался выбирать между двумя местами спеки и подал их как противоречие, что и есть его работа.

Desugar:

sql`SELECT * FROM users WHERE id = ${user_id} AND name = ${name}`
// эквивалентно
sql(
    ["SELECT * FROM users WHERE id = ", " AND name = ", ""],
    [user_id, name]
)

Tag-функция получает parts []str (сегменты, длина = args.len() + 1) и args []T. Сигнатура:

fn tag_name(parts []str, args []T) -> ResultType => ...

Стандартные теги stdlib MVP: json, sql, regex, bytes. html, css, graphql — user-space.

Compile-time validation через @comptime — для тегов без интерполяций (пустой args); если функция помечена, литерал проверяется при компиляции (некорректный JSON → compile error). В MVP @comptime откладывается на v2.

Multiline и raw escapes естественны:

ro r = regex`\d+\.\d+`               // не нужно дважды экранировать
ro q = sql`
    SELECT id, name
    FROM users
    WHERE created_at > ${cutoff}
`

Почему

1. Типобезопасная интерполяция — главное преимущество. Tag получает raw parts и args отдельно, сама эскейпит / передаёт через prepared statement (защита от SQL injection).
2. User-defined теги — обычные функции, любое имя.
3. Compile-time валидация через @comptime — JSON/regex/SQL без runtime-парсинга.
4. Прецедент JavaScript по синтаксису, Scala/Rust по compile-time.

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

• s"..." / r"..." (Scala) — ограничивает имя одним символом, нет user-defined.
• tag.raw("...") + tag.interp("...", args) — слишком многословно.
• Macros (Rust sql!) — требует механизма макросов.
• Implicit tag — ambiguity со строками. Амендмент (владелец, 2026-08-29): отказ СНЯТ, голая форма законна — решение «принимаем исследования», нормативно — D467 §5. Названная здесь двусмысленность снята не тегом, а ДЕЛИМИТЕРОМ: "…" и `…` — два разных литерала, и ни один не превращается в другой от появления идентификатора слева. Настоящая двусмысленность была в обратном: пока голая форма жила вне нормы, тело backtick зависело от НАЛИЧИЯ тега (с тегом — parts/args, без — сырая строка), и `a\nb ${x}` менял смысл от одного имени слева. Теперь тело разбирается всегда; тег решает только сборку.

Связь

• D33 — @comptime-теги без интерполяций могут быть const.
• D27 — parts и args — обычные []T.
• D40 — tag-функции обычные.
• 09-tooling.md → D24 — requires для валидации parts/args.

D49. Statement separator и парсинг выражений

Что

Перенос строки — основной разделитель statement’ов. ; — опциональный, нужен только при нескольких statement’ах на одной строке.

Правило

ro x = 1                        // newline разделяет
ro y = 2
foo(x, y)

ro a = 1; ro b = 2; foo(a, b)  // ; для одной строки (редко)

Лексер игнорирует NEWLINE, если statement очевидно продолжается:

1. После висящего бинарного оператора в конце предыдущей строки:

   ro total = a +
               b +
               c
   

2. Внутри открытых (, [, { — newlines игнорируются.

3. Перед . (method chain) и перед ? (error propagation):

   ro r = list
       .filter(|x| x > 0)
       .map(|x| x * 2)
       .sum()
   

4. После , в списках.

5. Перед else / else if — продолжение if-выражения:

   ro label =
       if s is Origin { "at-origin" }
       else if s is Circle { "circle" }
       else { "square" }
   

   Без этого правила multi-line if/else приходится писать через повторное присваивание let mut x = default; if ... { x = ... }.

6. Перед || / && / or / and — продолжение boolean expression:

   fn is_alnum(c char) -> bool {
       (c >= '0' && c <= '9')
       || (c >= 'A' && c <= 'Z')
       || (c >= 'a' && c <= 'z')
   }
   

   Это исключение из общего правила «бинарные операторы — в конце предыдущей строки» (Go-стиль). || и && часто пишут leading’ом для читаемости; обе формы допустимы. Реализовано через look-ahead в parse_or / parse_and.

Бинарные операторы — в конце предыдущей строки (Go-стиль) для большинства операторов (+, -, *, и т.п.). Исключения зафиксированы в правилах 5 и 6 выше: else/else if и ||/&&/or/and — leading-форма допустима. + в начале новой строки воспринимается как унарный.

Compound-assignment

Compound-операторы — синтаксический сахар:

Target обязан быть lvalue — одна из трёх форм:

// 1) Локальная mut-переменная
mut n = 0
n += 1                              // ✅

// 2) @field на self в методе (D35)
fn Counter mut @inc() -> () {
    @value += 1                     // ✅
}

// 3) Element массива/индексируемой коллекции
mut xs = [10, 20, 30]
xs[0] += 5                          // ✅

Compound-assign — это statement, не expression. После => в match-arm или в expression-body функции его нельзя писать без обёртки в { ... }:

match c {
    Some('\n') => { @line += 1; @col = 1 }     // ✅ блок
    Some(_)    => { @col += 1 }                 // ✅ блок
    None       => ()
}

// ❌ парсер не поймёт `+=` в expression-position arm:
// Some(_) => @col += 1

Правая часть compound-assign — обычное выражение (любое допустимое в RHS обычного =). Type-check соответствует базовому оператору: a += e валидно ⇔ a + e валидно и его тип присваиваем a.

Перегрузка через @plus/@minus/@times/@div (D46) работает прозрачно — compound на user-типе с @plus десахарится в a = a.plus(e).

Edge cases:

ro x = foo
(arg)                        // ❌ два statement'а: foo и (arg)

ro x = foo(arg)             // ✅ одна строка
ro x = foo(                 // ✅ открытая ( игнорирует newline
    arg
)

Trailing-block: ) и { на одной строке (D43).

Match-arms — , или \n оба разделяют:

match x {
    Some(v) => v * 2          // newline разделяет
    None    => 0
}

match x {
    Some(v) => v * 2,         // запятые тоже работают
    None    => 0,
}

Пустые ; запрещены — всегда баг.

Иерархия приоритетов (от низкого к высокому):

Строка ?? и её место ЗАМЕРЕНЫ, а не назначены (2026-08-30, реестр №841). До этого дня таблица не называла ни ??, ни !! вовсе — то есть два действующих оператора языка не имели записанного приоритета; пробел нашло окно 274 при подготовке волны и не стало закрывать его догадкой. Замеры СБОРКОЙ И ЗАПУСКОМ:

Отсюда место: строго МЕЖДУ сдвигами и аддитивными. Нумерация ниже сдвинута на единицу; проверено грепом, что номера уровней нигде не цитируются (0 совпадений по spec/ и docs/dev/), то есть они ярлыки порядка, а не идентификаторы. !! дописан к постфиксному уровню по уже записанной норме (04-effects.md: «имеет высший приоритет, тот же уровень, что ?») — это не новое решение, а перенос существующего в таблицу, где его ищут.

ВНИМАНИЕ: эта таблица описывает РАЗБОР, а не типизацию. Тем же замером обнаружено, что ?? ВООБЩЕ НЕ ПРОВЕРЯЕТ типы операндов: ro n = 5 и n ?? 99 даёт 99, то есть не-Option слева молча считается None и написанное значение теряется. Это дефект РЕАЛИЗАЦИИ, а не норма: реестр №839, блокер тега. Норма по-прежнему D86: слева обязан быть Option/Result, справа — ЗНАЧЕНИЕ нагрузки.

Грамматика (упрощённо):

program       = statement*
block         = '{' statement* '}'
statement     = ( decl | expr ) statement-end
statement-end = ';' | NEWLINE | look-ahead '}'

postfix-expr  = primary ( '.' name | '[' expr ']' | '(' args ')' | '?' )*
primary       = literal | identifier | '(' expr ')' | block | if | match | ...

Block-expressions в statement-позиции (Plan 148 Ф.2 clarification)

statement = ( decl | expr ) statement-end — в statement-позиции expr парсится полной postfix-expr грамматикой, без отдельной «block-statement» ветки. Это значит, что block-формы выражений ({ ... }, if, match, unsafe { ... }) в начале statement’а принимают постфикс (.method() / [i] / .field) напрямую, без обёртки в (…):

fn Vec[T Display] @display(mut sb StringBuilder) -> () {
    sb.append("Vec[")
    for i in 0..@len {
        if i > 0 { sb.append(", ") }
        unsafe { @data[i] }.display(sb)   // ✅ постфикс на unsafe-блоке
    }                                      //    без `(unsafe { … })`
    sb.append("]")
}

ro d = if cond { mk_a() } else { mk_b() }.doubled()  // ✅ постфикс на if
ro n = match tag { 1 => mk(99), _ => mk(0) }.field    // ✅ постфикс на match

Граница с bare { ... } блоком: если блок открывает statement и за ним нет постфикса, он остаётся обычным side-effecting expression-statement (его значение, если не trailing, отбрасывается) — никакого специального «block vs expression» форка в парсере нет; разбор единообразен. Постфикс привязывается ровно тогда, когда он синтаксически присутствует сразу после } (с учётом newline-tolerance правила 3 для ведущего .). Ранее unsafe { … }-форма документировалась как требующая (…) для постфикса — это устранено (закрывает backlog-маркер [M-138-unsafe-block-postfix-stmt]).

Почему

1. Современный тренд (Go/Kotlin/Swift/TS): newline-разделитель, меньше шума.
2. Простые правила вместо JS ASI — JavaScript ASI известный источник багов (return\n{...} возвращает undefined). Nova строит на «висящий оператор», «незакрытая скобка», «.method/?».
3. Бинарный оператор в конце — Go-практика, иначе унарный парсинг ломает выражение.

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

• Обязательный ; (Rust/C) — лишний шум.
• Indentation-significant блоки — конфликт с D40.
• JS ASI с edge cases — известный источник багов.
• Перенос оператора в начало строки — унарный/бинарный конфликт.

Связь

• D40 — внутри {} newlines разделяют statement’ы.
• D43 — ) и { на одной строке как частный случай.
• D45 — последнее выражение блока становится возвратом через newline-разделитель.
• 04-effects.md — handler-литералы используют те же правила внутри {...}.

D54. Операторы as и is

Что

Два оператора с разной семантикой:

• as — compile-time конвертация значения между совместимыми типами (numeric cast, newtype ↔ underlying, sum → int). Возвращает значение целевого типа. Если конвертация невозможна по правилам типов — ошибка компиляции.
• is — runtime type-check для значений типа any. Возвращает bool. Также используется как pattern в match и if для биндинга и smart cast’а.

as — про «сделай этим типом» (статически). is — про «проверь, какой это тип сейчас» (runtime).

Правило

as — compile-time конвертация

as работает в позиции выражения: <expr> as <type>. Возвращает значение целевого типа.

Numeric cast (см. D44):

ro n = 100 as u32           // литерал → u32
ro big = 0xFF_FF as u16
ro x = 1.5 as i32           // f64 → i32 (truncate)
ro y = some_int as f64       // int → f64

Семантика narrowing-конверсий

Поведение as при потере точности зависит от пары source→target. В отличие от C (где out-of-range float→int это UB), Nova даёт defined behavior на любом входе:

Float → integer — saturation, не UB. Out-of-range, NaN, ±Infinity дают defined значение, не зависящее от платформы:

• Out-of-range positive → INT_MAX / UINT_MAX.
• Out-of-range negative → INT_MIN / 0 (для unsigned).
• NaN → 0.
• +Infinity → INT_MAX / UINT_MAX.
• -Infinity → INT_MIN / 0.

Если нужна проверка out-of-range — используйте TryFrom:

ro n = f as i16                // saturation, infallible
ro n = i16.try_from(f)?         // throws Fail[OutOfRangeError]

as остаётся pure (без Fail-эффекта). Throw-форма доступна через D77 как explicit choice.

Прецеденты. Saturation для float→int согласован с Rust 1.45+ (RFC #2484 «sealed casts») — прямой аналог. C/C++ дают UB, Nova улучшает. Swift делает trap (panic), нет pure as — Nova выбирает saturation для совместимости с D54 «as это pure». Java делает IEEE round + wraparound (defined, но не saturation).

Newtype ↔ underlying (см. 02-types.md → D52):

type UserId u64

ro u UserId = 42 as UserId   // u64 → UserId
ro n u64 = u as u64           // UserId → u64

Sum → int (для sum’ов с числовыми discriminants, D52):

type ErrorCode enum NotFound = 404 | InternalError = 500
ro code = NotFound as int    // 404

Запрещено:

• any → T (x as int где x any) — нет статической конвертации. Используйте is-pattern или try_as[T]() (см. ниже).
• Произвольные типы без явного правила (User as Account) — ошибка компиляции.
• int → Sum через as — type-небезопасно (число может не попасть в варианты). Только через pattern match (см. D52).

Запрещённые as-cast’ы для char/u8/bool

Prune as-cast’ов где seemingly-numeric mapping выражает unsafe семантику. Программист должен использовать try_from/конверсию на источнике (с range-check’ом/парсингом) или explicit comparison:

AMEND (2026-08-01, owner decision, p-tryfrom) — str as T parse-строка ретрактирована. Прежняя форма T.try_from(s)? для str as int/i32/f64/bool/char противоречила канону Plan 174.1 + D77 R3 («конверсия — метод на ИСТОЧНИКЕ», тот же принцип, что уже применён к TimeZone.try_from → s.to_timezone(), D321 R6). Интегратор дважды спотыкался об это внутреннее противоречие спеки (таблица предписывала T.try_from(s)?, а фактический канон/реализация — s.to_*()). Канон: s.to_int()/s.to_u64()/ s.to_f64()/s.to_bool()/s.to_char() (std/runtime/string/parse.nv, Plan 174.1) — каждый возвращает Result[T, E], ?/.ok()/match работают идентично прежней try_from-форме. T.try_from(s str) для примитивов (int/i64/u64/f64/bool/char) был чистым compiler-интринзиком без единой .nv-декларации — эмит-ветка удалена (emit_c.rs), вызов теперь честная ошибка компиляции [E_UNKNOWN_STATIC_METHOD]. Числовые/char narrowing-конверсии (char.try_from(n int), u8.try_from(c char)) — отдельная, легальная ветка try_from, НЕ затронута этим амендментом (см. блок ниже).

Исключение для char-литералов: 'A' as int, 'A' as u8 разрешены — программист видит codepoint буквально на write-time, range-check не нужен.

Исключение для int-литералов → char: 0x41 as char, 65 as char разрешены, если литерал — compile-time-known integer в валидном Unicode-диапазоне U+0..=U+10FFFF исключая surrogate range U+D800..=U+DFFF. Range-check выполняется статически в checker’е, runtime Fail не нужен. Off-range литерал — compile error с указанием конкретного codepoint (не generic suggestion). Для переменных типа int правило прежнее — нужен char.try_from(n)?. Введено в Plan 14 Ф.7 (2026-05-09).

Исключение для unsafe { } блоков: внутри unsafe { } запрещённые as-cast’ы для переменных разрешены без range-check. Программист берёт ответственность за корректность значения. Основное применение — реализация char.try_from и аналогичных stdlib-функций где range-check уже выполнен явно перед cast’ом:

export fn char.try_from(cp int) -> Result[char, str] {
    if cp < 0 || cp > 0x10FFFF || (cp >= 0xD800 && cp <= 0xDFFF) {
        Err("char.try_from: invalid codepoint")
    } else {
        Ok(unsafe { cp as char })
    }
}

Прецеденты. Rust требует char::from_u32(n) (Result), не n as char. Swift Character.init(extendedGraphemeClusterLiteral) — нет прямого n as Character. Kotlin n.toChar() существует но deprecated для unsafe usage. Java (char)n — narrow с silent overflow (UB-class). Nova выбирает Rust-стиль strict.

Bool-restrictions — то же из Rust/Swift/Kotlin: if cond требует bool, n as bool — explicit ошибка с suggestion. Это закрывает известный bug-class C/JavaScript/Python.

Strict if cond: bool / while cond: bool

if cond { ... }, while cond { ... }, cond1 && cond2, cond1 || cond2 — cond обязан быть bool. C-стиль truthy-int (if a где a: int) запрещён.

ro n int = 5
if n { ... }          // ❌ compile error: cond must be bool
if n != 0 { ... }     // ✅ explicit comparison

Прецеденты. Rust/Swift/Kotlin/Go (если игнорировать nil-check shortcut) — все требуют bool. Python/C/JavaScript разрешают truthy — известный bug-class.

is — runtime type-check

is работает в двух сценариях:

1. any → T — type-check для значений top-type’а any. Возвращает bool (или используется как pattern в match).
2. Sum → Variant — variant-check для sum-значений: «является ли это значение конкретным вариантом sum-типа?» (revision v2).

На остальных «обычных» типах (record без вариантов, primitives, аносу́ты) is — ошибка компиляции: тип известен статически, проверка бессмысленна.

Сценарий 1: any is T

Boolean-выражение:

fn dump(x any) Io -> () =>
    if x is int { println("got int") }
    if x is str { println("got str") }

Pattern в match:

match arg {
    n is int  => process_int(n)         // биндинг + smart cast
    s is str  => process_str(s)
    is bool   => println("bool")        // без биндинга
    _         => throw UnsupportedType
}

Pattern-форма: <binding> is <type> или is <type> (без биндинга).

Smart cast в if:

fn process(x any) -> str =>
    if x is str {
        x.upper()              // x здесь имеет тип str автоматически
    } else if x is int {
        str.from(x)             // x здесь int (D73)
    } else {
        "unknown"
    }

После if x is T { ... } внутри блока компилятор автоматически уточняет тип переменной до T (Kotlin smart cast). Работает если переменная не переприсваивается в блоке.

Сценарий 2: <sum> is <Variant>

is работает на любом sum-значении, проверяя соответствие конкретному варианту:

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

ro s Shape = Circle { radius: 1.0 }

if s is Circle { println("circular") }       // ✅ true
if s is Square { println("squarish") }        // ✅ false
if s is Origin { println("at origin") }       // ✅ unit-вариант

// Также для prelude sum-типов:
ro r Result[int, str] = Ok(42)
if r is Ok    { println("happy path") }      // ✅
if r is Err   { handle_error() }              // ✅

ro opt Option[User] = Some(u)
if opt is Some { ... }
if opt is None { ... }

Без биндинга — is это просто bool. Для извлечения значения из варианта используется pattern-bind if (D34), который комбинирует check и binding в одном выражении:

// Без биндинга — только yes/no:
if r is Ok { println("ok") }

// С биндингом — pattern-bind if:
if Ok(n) = r { use(n) }

Это даёт чёткое разделение:

• is = «yes/no» (короткий guard).
• if Pattern = expr = «yes + extract» (binding form, D34 — без let).

Поэтому is не поддерживает binding-форму на sum-типах — r is Ok(n) ошибка, нужно if Ok(n) = r. Это согласовано с D9 «один очевидный путь»: одна форма для одной задачи.

Реализация: компилятор знает теги вариантов и эмитит runtime-проверку tag’а sum-struct’а (shape->tag == NOVA_TAG_Shape_Circle). Стоимость — одно сравнение integer’ов.

На не-sum / не-any — ошибка компиляции:

type User { id u64 }
fn process(x User) -> () =>
    if x is int { ... }       // ОШИБКА: User — record, не sum и не any

Методы на any для extraction (комплементарные is)

Для pattern-bind-if-стиля и работы через эффект Fail:

// Опциональный cast — Option[T]
fn any.try_as[T](x any) -> Option[T] =>
    // runtime-проверка тэга, Some если совпал, None иначе

// Cast через Fail — для строгих случаев
fn any.as[T](x any) Fail[TypeMismatch] -> T =>
    // throw TypeMismatch если тег не совпал

Использование:

// pattern-bind if
if Some(n) = arg.try_as[int]() {
    process_int(n)
}

// ?-стиль
ro n int = arg.as[int]?

Три инструмента под разные сценарии:

Почему

Раздельные as и is — два разных вопроса

as — «как сделать значение типа T» (compile-time, статически решаемая задача). is — «какой тип у значения сейчас» (runtime, нужен для top-type extraction).

В языках, использующих один оператор для обоих (Swift as/as?/as!, C++ static_cast/dynamic_cast), программист путается. В Nova разделение явное — два keyword’а с непересекающимися ролями.

is для any и sum-типов — без overhead на остальных типах

is работает там, где runtime-tag уже есть структурно:

1. any-значения содержат tag дискриминирующий конкретный тип (boxing-цена для top-type — обязательная).
2. Sum-типы содержат tag дискриминирующий вариант (это часть layout’а sum-struct’а — tag + payload).

Для record/primitives/protocol — tag’а нет, и is ошибка компиляции: тип уже известен статически, проверка бессмысленна.

В Kotlin/C# is T работает на любом типе через RTTI (Runtime Type Information) — каждое значение несёт type-tag. Это глобальный overhead. Nova избегает этого: is использует существующие теги (any-boxing, sum-discriminant), не добавляет новых. Поэтому стоимость is localized.

Sum-вариант check vs match:

// Короткая форма для yes/no:
if shape is Circle { return "round" }

// Полная форма с biding'ом. Варианты выше объявлены RECORD-формой
// (`Circle { radius f64 }`), поэтому и разбираются ФИГУРНО:
if Circle { radius } = shape { use(radius) }

// Exhaustive обработка:
match shape {
    Circle { radius } => ...
    Square { side }   => ...
    Origin            => ...
}

АМЕНДМЕНТ 2026-08-17 (аудит самосогласованности, раздел 4, пункт 5; реестр 221.1 №719). Здесь стоял ПОЗИЦИОННЫЙ разбор — Circle(r), — хотя двумя абзацами выше те же варианты объявлены record-формой Circle { radius f64 }. Нормативна фигурная форма: таблица форм spec/syntax.ru.md («( ... ) — позиционный вариант, { ... } — record-вариант») и канонический разбор того же Shape в 02-types.md.

Это не опечатка без последствий: форма приехала ИЗ ЭТОГО ПРИМЕРА в компилятор — чекер её принимал, а кодоген падал no member named '_0', то есть ошибка чужого компилятора в лицо пользователю. Отказ E_RECORD_VARIANT_POSITIONAL_PATTERN заведён той же волной, и заведён в ЕДИНОМ обходе образцов — иначе if Circle(r) = s остался бы живым мимо проверки в match. Починить компилятор и оставить пример значило бы продолжать учить неверной форме.

Каждая форма для своего сценария: is — guard, pattern-bind if — guard + extract, match — exhaustive multi-way.

Smart cast — стандартная эргономика

if x is T { x.method_of_T() } без явного re-binding — фича Kotlin, TypeScript narrowing, C# pattern matching, Swift binding-pattern. Все сообщества любят smart cast, и этого не избегают.

Прецеденты ключевых слов

• as: Rust, Swift, C#, Kotlin, TS — для cast (numeric и иначе). Nova берёт это значение.
• is: C# (x is T), Kotlin (x is T), TS (typeof/instanceof, но не is — is в TS это type predicate). F# использует :?, что менее красиво. Nova берёт C#/Kotlin-стиль.

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

• Один оператор для cast и type-check (Swift as?/as!). Усложняет mental model, путает пользователя.
• is T для любого типа без tag’а (Kotlin-style RTTI). Требует runtime-tag на всех значениях — глобальный overhead. Nova ограничена типами, у которых tag уже есть структурно (any-boxing, sum-discriminant). Для record/primitives — compile error.
• is Variant(binding) с биндингом на sum-типах. Дублирует if Variant(binding) = expr (D34). Чтобы избежать двух форм для одной задачи — is без binding, pattern-bind if с binding.
• x.is[int]() метод вместо оператора. Менее читаемо в условиях (if x.is[int]()-запись хуже if x is int). Operator проще.
• as для any → T без runtime-проверки. Type-небезопасно (программист может написать x as int для x any без гарантии). Используйте is или try_as[T].
• Implicit cast между типами без as. Все конвертации явные.
• Flow-sensitive narrowing на !is в MVP. Для if !(x is T) { return } после блока x не уточняется автоматически. Можно расширить позже.

Цена

1. Два keyword’а в синтаксисе языка вместо одного. is ранее не использовался — теперь зарезервирован.
2. Runtime-tag для any-значений — стоимость в реализации (memory overhead на boxing).
3. Smart cast требует поддержки в type-checker — переменная имеет разный тип в разных ветках одной функции. Усложняет реализацию.
4. try_as[T]() и as[T]? — два метода stdlib на any поверх оператора is. Нужно зафиксировать в prelude (D26).

Связь

• 02-types.md → D52 — newtype, sum, discriminants — типы, для которых as определён.
• 02-types.md → D53 — any как пустой protocol-тип, для которого работает is.
• D44 — numeric as-cast (100 as u32) как частный случай D54.
• D34 — if Some(n) = x.try_as[T]() использует pattern-bind-форму (D34).
• D19 — => в match-arms, is-pattern наследует ту же стрелку.
• 08-runtime.md → D26 — try_as и as методы на any в prelude.

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

• Flow-sensitive narrowing на !is — можно ли после if !(x is T) { return } уточнять тип в продолжении функции? Отложено.
• is для protocol-types (runtime structural check) — дорого, не входит в MVP.
• is для error/cancel-detection в Result[T, E]. r is Err работает (variant check), но иногда хочется проверить конкретный payload — r is Err(NotFound). Сейчас это не поддерживается (binding запрещён), нужно if Err(NotFound) = r.

Эволюция

v1: is работал только для any-значений. Sum-варианты проверялись через match или pattern-bind if — короткой is-формы не было. Это вынуждало писать convention @is_circle() методы для часто проверяемых вариантов, что засоряет API типов.

v2 (текущая, 2026-05-06): is расширен на sum-варианты — shape is Circle работает. Cтоимость localized: tag для sum уже есть в layout’е, никакого нового runtime-overhead’а. Биндинг-форма не добавлена — это работа pattern-bind if (D34); чёткое разделение ролей: is = yes/no, pattern-bind if = yes + extract.

Это убрало нужду в @is_X convention’ах из syntax.md.

Эволюция

До D54 as использовался без формального D-решения (упоминался в D44, D52). D54 фиксирует семантику явно: as — compile-time конвертация; is — runtime type-check. Закрывает Q-any-extract (извлечение типа из any-значения).

Реализация is/try_as на any (Plan 174.3, 2026-07-04)

v1 any-downcast (был спроектирован, но не реализован в codegen — any не имел рабочего value-представления) теперь реализован поверх type_id-реестра Plan 61.

Runtime-представление any (D53). any — тип-стёртый void*, указывающий на heap-boxed NovaAny:

typedef struct { NovaTypeId type_id; const char* name; } NovaTypeInfo;
typedef struct { const NovaTypeInfo* info; void* data; } NovaAny;

info — per-type статический NovaTypeInfo (несёт type_id из реестра Plan 61 + имя для Display/диагностик); data — отдельная GC-allocation с копией payload. И box, и payload сканируются консервативным GC. any остаётся void* в ABI (нулевой blast-radius на erased-void*-код: print/println, generic-параметры).

Операции:

• upcast T → any (boxing): nova_any_box(&NOVA_TYPEINFO_<T>, &v, sizeof(T)). Явный v as any и неявный по D53-supertype — аргумент к any-параметру, ro x any = <concrete>, fn … -> any => <concrete> — боксируются автоматически.
• x is T (x: any): nova_any_is(x, NOVA_TID_<T>) — сравнение type_id.
• x.try_as[T]() -> Option[T]: при совпадении type_id — Some(*(T*)nova_any_data(x)), иначе None.
• flow-narrowing if x is T { … }: внутри блока x уточняется до T (Kotlin smart-cast) — payload-deref, aliased через #define.

Диагностика [E_IS_NON_ANY] (чекер): is на операнде, чей тип статически известен как не-any и не-sum (record / примитив) — ошибка компиляции (проверка бессмысленна). Чистый span+код, не CC-FAIL.

Отложено (followup [M-174.3-*]): форма x.as[T]? (Fail-downcast — парсер не принимает .as member, as — ключевое слово); match { n is T => … } pattern-форма (реализована операторная/if-форма + try_as); гетерогенные []any + Display (Ф.3).

D58. Range-литерал, Iter[T] protocol, for x in c implicit iter

Amend (Plan 138): правило for x in c изменено — iter() всегда первым. Итераторы обязаны реализовывать iter() -> Self (trivial).

Amend (Plan 152.1 / D250, 2026-06-13): for c in s (s: str) → char через str @iter() => @as_chars() (CharsIter, codepoint-итератор). Default-единица итерации строки — codepoint (как Go for range, Swift for c in s). Codegen: str’s C-тип nova_str (lowercase, lang-item) маппится в for-in на ключ “str” → Case 2 синтезирует s.iter(). Байтовая итерация — явно for b in s.as_bytes().

Что

Три связанных правила, объединённых одним D-блоком, потому что они взаимно поддерживают друг друга:

1. a..b и a..=b — литералы Range в любой expression-позиции (не только в for). Open-ended формы a.., ..b, ..=b, .. — расширение Plan 96 (D144): только в slice- context (arr[range]). В materialize / for-loop / quantifier / parallel-for — compile-error (нужна bounded форма).
2. Iter[T] — структурный protocol в prelude (D26): protocol { mut next() -> Option[T] }. Любой тип с таким методом — итератор.
3. for x in c — всегда через iter(). Десугаринг: { mut _it = c.iter(); loop { match _it.next() { Some(x) => body, None => break } } }. Итераторы реализуют iter() -> Self (trivial) — единая точка входа.

Правило

Range-литералы

ro r1 = 0..5             // Range { start: 0, end: 5 }   half-open [0, 5)
ro r2 = 0..=5            // Range { start: 0, end: 6 }   нормализован компилятором

ro r Range = 1..10       // в ro-binding'е работает
fn count(r Range) -> int => r.end - r.start
count(0..100)              // в позиции аргумента работает

ro ranges []Range = [0..5, 10..20, 100..200]   // в массиве

a..b — синтаксический сахар, разворачивается компилятором в Range { start: a, end: b }. a..=b → Range { start: a, end: b+1 } (нормализуется, inclusive не хранится).

Конструкторов Range.exclusive/Range.inclusive нет — лишний API.

Range — value record (Plan 138 Ф.0.3):

export type Range value {
    ro start int
    ro end   int      // half-open: end НЕ включён
}

Stack-allocated, 16 bytes. Методы: @iter(), @contains(x), @len(), @is_empty().

Next[T] + Iter[I] протоколы (D241+D242)

Конвенция: имя протокола = магический метод.

// Итератор — умеет выдавать следующий элемент.
export type Next[T] protocol {
    mut @next() -> Option[T]
}

// Источник итератора — умеет превращаться в итератор.
// I — конкретный тип итератора (реализует Next[T] для некоторого T).
export type Iter[I] protocol {
    @iter() -> I
}

Итераторы реализуют оба протокола: Next[T] + Iter[Self] (trivial => self). Коллекции реализуют только Iter[SomeIter].

// Итераторы:
fn RangeIter mut @next() -> Option[int] => ...
fn RangeIter @iter() -> RangeIter => self        // Iter[RangeIter]

fn VecIter[T] mut @next() -> Option[T] => ...
fn VecIter[T] @iter() -> VecIter[T] => self      // Iter[VecIter[T]]

// Коллекции — только @iter():
fn Range @iter() -> RangeIter => ...             // Iter[RangeIter]
fn Vec[T] @iter() -> VecIter[T] => ...          // Iter[VecIter[T]]

Generic bound для «принять любой iterable»:

fn collect[C Iter[I], I Next[T], T](c C) -> Vec[T] {
    mut result = Vec.new()
    for x in c { result.push(x) }
    result
}

for x in c — implicit iter

for-loop принимает любое выражение справа от in, разворачиваясь по правилу:

for x in c { body }

десугарится компилятором двухфазно (как Rust IntoIterator + Iterator):

Фаза 1: mut _it = c.iter()          // всегда вызвать iter() один раз
Фаза 2: loop { match _it.next() { Some(x) => body, None => break } }

Правило:

1. Если c имеет iter() — вызвать, получить итератор, перейти к фазе 2.
2. Если c не имеет iter() но имеет next() — fallback: использовать напрямую (backward compat; рекомендуется добавить iter() -> Self).
3. Иначе — ошибка компиляции.

Итераторы реализуют iter() -> Self — поэтому for x in iter_obj тоже работает через единый путь: iter_obj.iter() возвращает тот же объект, фаза 2 вызывает next(). Нет бесконечного цикла: компилятор вызывает iter() ровно один раз (фаза 1), дальше только next().

ro v []int = [1, 2, 3]
for x in v { ... }                   // v.iter() → VecIter → next()

ro r = 0..5
for x in r { ... }                   // r.iter() → RangeIter → next()
for x in 0..5 { ... }                // то же

mut it = v.iter()
for x in it { ... }                  // it.iter() → self → next() (trivial)

Почему

1. Range как expression — естественно. В for-loop 0..n уже работает. Расширение на любую expression-позицию устраняет асимметрию: «range можно в for, но не в let». Прецедент Rust, F#, Haskell, Scala.
2. Iter[T] как protocol — fits structural typing. Никакого специального механизма, обычный protocol с одним методом. Прецедент Rust Iterator-trait, OCaml Seq.t, Python __iter__.
3. for x in c без .iter() — стандарт mainstream. Kotlin, Swift, Python, C#, Rust (через IntoIterator) — везде sugar. Только Go требует range-keyword.
4. AI-friendly. for x in c короче, чем for x in c.iter(). Меньше boilerplate, меньше ошибок «забыл .iter()».

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

• Range только в for-loop (текущая ситуация до D58). Ограничивает использование — нельзя передать range как аргумент, сохранить в переменную.
• Range как примитив языка (без Range-типа в stdlib). Полезно, но изоляция от системы типов хуже — нельзя добавить методы, написать функцию, принимающую Range.
• for x in c строгое — только Iter[T] (без implicit iter() сахара). Программист пишет for x in v.iter() каждый раз, избыточно.
• for-in через специальный keyword (Go range). Лишний синтаксис, нет преимущества над implicit iter через protocol.

Цена

1. Range type в prelude. Расширение D26 (prelude растёт).
2. a..b как expression. Парсер должен понимать a..b в любой expression-позиции, не только в for. Лёгкая правка грамматики.
3. for-in-сахар. Компилятор делает desugaring for x in c → выбор c.iter() vs использование c напрямую. Простое правило, но требует type-resolution.
4. Iter[T] имя. Короткое, но конфликтует с потенциальными user-defined type’ами Iter. Согласовано с D30 (типы PascalCase).

Связь

• 02-types.md → D42, D53 — Iter[T] как обычный protocol через структурную типизацию.
• D38 — 0..n как range-выражение в существующем синтаксисе for-loop.
• 08-runtime.md → D26 — Iter[T], Range, RangeIter в prelude.
• 02-types.md → D355 — blanket methods на Next[T] implementors: fn[I Next[T]] I @m диспетчируется на любой C impl Next[T]; ≤1 impl инвариант (D355 §4, ex-D282). Cross-ref: D241+D242 (Plan 161 Ф.4).

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

• Reverse range (5..0 или (0..5).reverse()) — что значит range с start > end? Пустой? Идущий назад? — открытый Q-range-extras.
• (0..5).step(n) — step-итерация. Q-range-extras.
• collect[Out]() generic-collection-construction — требует bound’ов (Q-bounds) и static-method-protocol. Q-collect-mechanism.
• Type-as-value (передача типа как значения, xs.collect([]int)) — отдельный вопрос Q-type-as-value.
• @-префикс в protocol-методах — ✅ RESOLVED Plan 108.4 (2026-06-09). @ обязателен перед instance-методами в protocol declarations. ro/mut/consume prefix перед @ для receiver mutability. Default = ro. Type-checker enforces impl match. См. D209.
• Static-метод в protocol через .method()-префикс — ✅ RESOLVED Plan 97 (2026-05-23). Leading-точка .method(args) -> Ret в protocol {} теле помечает метод статическим (симметрично D35 fn Type.name); реализация ожидается через fn Type.method(...). From/TryFrom обновлены под новый синтаксис (.from(t T) -> Self/ .try_from(t T) -> Result[Self,E]). Hard-enforcement static↔instance mismatch — followup.

⚠️ D58 AMENDED by Plan 108.4 (2026-06-09) — Protocol declaration of Iter[T] / Iterable[T] now uses mut @next() -> Option[T] (explicit @

• mut receiver). The @-prefix is required for all protocol instance-methods (D209). Use-site structural conformance (for-in loop, [T Iterable[U]] bound) checks receiver_mut: a type that declares @next() (ro) does NOT satisfy Iterable[T]. Bootstrap parser limitation comment in std/prelude/collections.nv has been removed. All existing implementers (Counter, RangeIter, VecIter, etc.) already used mut @next() — no implementer changes required.

D59. Array, tuple и позиционные partial patterns

Что

Pattern matching на массивах ([]T), кортежах ((A, B)) и позиционных конструкторах sum (Cons(T, T')). Покрывает разрозненные фичи, которые уже использовались в examples ([], [r], [_, ..], Cons(..)), но не были формально зафиксированы.

.. (rest-pattern) — единый маркер «остальные элементы игнорируются» во всех трёх контекстах: record ({ field, .. } — D17/D52), позиционные конструкторы (Cons(..), Click(x, ..)), массивы ([head, ..], [.., last], [a, .., z]).

Правило

Array patterns

match xs {
    []           => "empty"                  // пустой массив
    [x]          => "one: ${x}"               // ровно 1 элемент, bind в x
    [a, b]       => "two: ${a}, ${b}"          // ровно 2
    [a, b, c]    => "three: ..."                // ровно 3
    [head, ..]   => "first: ${head}"            // ≥1, bind первого
    [.., last]   => "last: ${last}"             // ≥1, bind последнего
    [a, .., z]   => "first/last: ${a}, ${z}"   // ≥2, bind первого+последнего
    [_, ..]      => "non-empty"                  // ≥1, без bind
    [_, _, third]=> "exactly third"              // ровно 3, bind третьего
    _            => "other"                       // wildcard
}

Правила:

1. Ровные позиции ([a, b], [a, b, c]) — соответствуют точной длине.
2. .. rest-pattern — означает «0 или больше элементов». Допустим в позициях:
   • [items, ..] — head + остальное.
   • [.., items] — остальное + last.
   • [a, .., z] — head + middle (игнорируется) + last.
3. ..items с биндингом — biind остатка как массива:

   match xs {
       [head, ..rest] => process(head, rest)    // rest : []T
       [.., last]     => last                     // без bind остального
   }
   

4. _ placeholder — игнорировать один элемент, точно как в record.
5. Не более одного .. в массиве-pattern — иначе ambiguous (Rust то же правило).

Tuple patterns

ro p = (1, "alice", true)

match p {
    (1, _, true)        => "first variant"
    (n, name, _)        => "n=${n}, name=${name}"
    _                   => "other"
}

ro (a, b, c) = (1, 2, 3)                  // destructuring ro
ro (x, _, z) = (1, 2, 3)                   // ignore middle

Правила:

1. Tuple-pattern соответствует точно — длина фиксирована типом.
2. .. в tuple запрещён (длина известна на этапе типизации, .. не нужен).
3. Деструктуризация в let через tuple-pattern — поддерживается.

Positional sum-variant partial-pattern

type LinkedList[T] | Empty | Cons(T, LinkedList[T])

match list {
    Empty       => "nil"
    Cons(h, _)  => "head only"                  // явный _ для tail
    Cons(..)    => "non-empty"                   // partial: оба поля игнорируются
    Cons(h, ..) => "head: ${h}"                  // bind первого, остальное ..
}

type Event enum Click(int, int) | Move(int, int, int) | Idle

match event {
    Idle             => "idle"
    Click(..)        => "click"
    Move(x, ..)      => "move at x=${x}"
    Move(.., z)      => "move with z=${z}"
    _                => "other"
}

Правила:

1. .. в позиционном конструкторе работает так же, как в массиве: head/tail/middle-rest.
2. Один .. на конструктор.
3. Согласовано с D17/D52 partial-pattern для record-форм.

Почему

1. Используется в examples. effect-density/repository.nv, orm_demo.nv, stdlib_linkedlist.nv уже активно применяют [], [r], [_, ..], Cons(..). Без формализации парсер не знает грамматику, LLM не знает правила, code review не имеет опоры.
2. Прецедент Rust. Array/tuple/sum-positional patterns в Rust имеют точно такой синтаксис ([], [head, ..], [.., tail], Variant(..)). Программисты с Rust-фоном узнают мгновенно.
3. Единый .. для всех partial-форм. Record (D17/D52), позиционный sum, массив — везде .. означает «остальное игнорируется». Один концепт.
4. Tuple destructuring в let — стандартная фича современных языков (Rust/Swift/Kotlin/Python).

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

• Cons(_, _) как единственная форма для позиционного sum. Шумно для конструкторов с 3+ полями (Move(_, _, _)). С .. → Move(..).
• Cons-list pattern (head :: tail) для массивов, как в Scala/OCaml. Nova не имеет cons-семантики массивов — []T это slice, не linked list. Используем bracket-syntax.
• Multiple .. в одном pattern ([a, .., b, .., c]). Ambiguous — какое .. сколько элементов берёт? Запрещено.
• .. в tuple-pattern. Длина tuple фиксирована, .. не несёт информации. Запрещено для строгости.
• Slice-binding [head, ..rest] с типом rest : []T — частично отложено. Bind через ..items (без значения по умолчанию) поддерживается. Расширения вроде [a, b, ..rest, c, d] (rest в середине с bind) — не в MVP.

Цена

1. Парсер усложняется — три новых формы pattern (array, tuple, positional-rest). Стандартное расширение, прецедент Rust.
2. Exhaustiveness check для массивов сложнее. Длина динамическая, компилятор не может проверить «все случаи покрыты» как для sum-вариантов. Wildcard _ обязателен в array-match, если не покрыты все возможные длины (которых бесконечно). Это как в Rust.
3. ..items slice-binding требует runtime-аллокации сегмента массива (rest : []T). В zero-copy случае — rest это slice (start, len). Согласовано с D32 (slice-семантика).

Связь

• D17, D52 — partial-pattern .. для record-форм. D59 расширяет на массивы и позиционные конструкторы.
• D27 — []T как тип, на котором работают array-patterns.
• D34 — pattern-bind в условиях; array/tuple-patterns доступны и в pattern-bind if/while (D34).
• Закрывает Q-positional-partial-pattern.

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

• [a, b, ..rest, c] — rest в середине с bind. Не в MVP.
• Slice-bind на массиве с []int.alloc(...) vs zero-copy slice — деталь runtime, не дизайн.
• String-as-array patterns (match s { "hello" => ..., _ => ... } — strings как массивы char) — отдельный вопрос Q-string-patterns.

D60. Spread ...x в литералах: массив и record

Что

Оператор ... (три точки) внутри array- и record-литералов вставляет элементы/поля из существующего значения. Двойственная к D59 partial-pattern: D59 разбирает, D60 строит.

ro arr1 = [1, 2, 3]
ro arr2 = [0, ...arr1, 4]                  // [0, 1, 2, 3, 4]

ro user1 = User { id: 1, name: "alice", email: "a@x.com" }
ro user2 = { ...user1, name: "bob" }        // copy + override name

Правило

Array spread

ro a = [1, 2, 3]
ro b = [4, 5]

ro c = [...a, ...b]                         // [1, 2, 3, 4, 5]
ro d = [0, ...a, ...b, 6]                    // [0, 1, 2, 3, 4, 5, 6]
ro e = [...a]                                // копия (не reference)

Правила:

1. Источник ...src должен быть []T, где T совпадает с типом элементов целевого массива.
2. Несколько spread’ов в одном литерале разрешены: [...a, ...b, ...c].
3. Смешивание spread и обычных элементов — в любом порядке: [1, ...a, 2, ...b, 3].
4. Стоимость: O(total length) — концептуально concatenation. Компилятор может оптимизировать (пред-аллокация по сумме длин).

Record spread

type User { id u64, name str, email str, role str }

ro alice User = { id: 1, name: "alice", email: "a@x.com", role: "user" }

// Override одного поля:
ro alice2 = { ...alice, name: "ALICE" }

// Override нескольких:
ro admin_alice = { ...alice, role: "admin", email: "admin@x.com" }

// Все поля из spread — то же значение:
ro copy = { ...alice }                       // эквивалентно alice (но новый record)

Правила:

1. Источник ...src должен быть того же типа, что и target (или иметь совпадающее множество полей).
2. Override: явные field: value после ...src перезаписывают значения из spread. Порядок в литерале — left-to-right.

   ro r = { ...src, name: "new", ...override, id: 99 }
   //           ↑       ↑          ↑           ↑
   //  src.все   override("name")  override.все  override("id"=99)
   

3. Все required-поля должны быть покрыты — компилятор проверяет. Если spread + явные не дают полного покрытия — ошибка.
4. Один spread на record-литерал в MVP. { ...a, ...b } — отложено (нужны правила приоритета).
5. Тип источника: в MVP — строго тот же тип, что target. В будущем — может быть подтип/совпадение по полям (требует structural-subtyping, Q-anonymous-union).

Совместимость с D52 literal coercion

type User { id u64, name str }

ro u User = { id: 1, name: "alice" }              // D52 record-coercion
ro u2 User = { ...u, name: "bob" }                 // D60 spread + D52 coercion
ro u3 User = { ...u }                              // полный copy через spread

В позиции с явным целевым типом spread работает с D52-coercion: имя типа подразумевается из аннотации.

Совместимость с D17/D52 field punning

ro name = "bob"
ro u User = { ...other, name }                     // shorthand + spread

Field punning (D52) работает после spread — если имя поля совпадает с переменной в scope, shorthand обязателен.

Почему

1. Immutable update. В функциональном стиле (доминирующем в Nova: mut через эффект, GC по умолчанию) immutable-обновление record — частая операция. Без spread:

   ro u2 = User { id: u.id, name: "bob", email: u.email, role: u.role }
   

   С spread: { ...u, name: "bob" }. Краткость + защита от ошибок (если в User добавилось поле, программист не должен обновлять каждый use-site).

2. Concatenation массивов. [head, ...rest] — элегантнее [head].concat(rest) или ручного цикла.

3. Прецедент TypeScript. ...spread массово используется в современном TS/JS. Программисты знают.

4. Симметрия с D59 partial-pattern. D59 разбирает значение через .., D60 строит через .... Концептуально — две стороны одной медали. Разные токены (.. vs ...) убирают синтаксическую путаницу.

5. AI-friendly. LLM генерирует { ...other, name: "bob" } — очевидное намерение, нет boilerplate.

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

• .. (две точки) для spread (Rust struct-update style). Конфликт с range-литералом (D58) и rest-pattern (D59). Парсер мог бы различать по контексту, но ... (три точки) однозначен и согласован с TS-прецедентом.
• *arr/**obj (Python-style). Два разных оператора для array vs record — лишнее. Один ... для всего.
• { src with name = "bob" } (OCaml-style with-keyword). Новый keyword, менее знакомый, не симметричен с array-spread.
• Multiple record-spread { ...a, ...b } в MVP. Семантика «правый перезаписывает» интуитивна, но требует продумать edge-cases (что если поле есть в обоих и target требует один тип — компилятор должен проверить). Отложено до measured-need.
• Spread в pattern-position (match xs { [1, ...rest, 5] => ... }). D59 уже даёт [head, ..rest] через две точки — отдельный механизм для destructuring. ... остаётся только для construction.
• Spread с подтипом. В MVP target и source строго одного типа. Расширение — Q-spread-subtype.

Цена

1. Парсер расширяется — ...expr в array/record литералах. Стандартное расширение, прецедент TS.
2. Type-checker проверяет покрытие required-полей при spread в record. Не сложнее, чем уже есть для D55 literal coercion.
3. Runtime cost array-spread — O(total length). Программист знает (концептуально concat).
4. Runtime cost record-spread — O(field count) копирование полей. Минимально, по аналогии с обычным record-литералом.

Связь

• D52 — record-coercion. D60 расширяет: spread в позиции с явным типом тоже coerce’ится.
• D17/D52 field punning — { ...src, name } shorthand работает после spread.
• D58 — .. (две точки) для range. D60 использует ... (три точки) для spread — разные токены, нет конфликта.
• D59 — partial-pattern .. в destructuring. D60 — spread ... в construction. Двойственные операции, разные синтаксисы.
• D27 — []T как тип, на котором работает array-spread.

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

• Multiple record-spread ({ ...a, ...b, ... }) — отложено.
• Spread с подтипом/совпадением полей — Q-spread-subtype.
• Spread в tagged template literal args — нет в MVP, не нужен.
• Tuple-spread ((1, ...t, 5)) — длина tuple фиксирована типом, spread даёт компилятору всю информацию. Не вводится в MVP за ненадобностью.

D69. Variadic-параметры через ...items []T

Что

Последний параметр функции может быть помечен префиксом ... — параметр объявляет, что на call site его можно вызвать одним из двух способов:

1. Через spread существующего массива: f(...arr).
2. Через отдельные элементы: f(a, b, c) — компилятор соберёт их в []T.

Тип параметра — обычный []T. Внутри функции items это []T, никакой специальной семантики.

Правило

Декларация

fn print[T](...items []T) Io -> () {
    for x in items {       // items: []T внутри функции
        Io.write(str.from(x))
    }
}

fn fmt(template str, ...args []str) -> str {
    // template — обычный параметр; args — variadic []str
    ...
}

Грамматика:

param = [ '...' ] name type

... допустим только перед последним параметром. Тип после ... обязан быть []T (или []Type любой формы) — не element type.

Call site

// Способ 1: spread массива
ro names = ["alice", "bob"]
print(...names)            // эквивалентно print("alice", "bob")

// Способ 2: отдельные элементы
print("alice", "bob")      // компилятор собирает в ["alice", "bob"]

// Микс — spread в любой позиции после обычных аргументов
print("prefix", ...names, "suffix")
//      ↑          ↑          ↑
//      обычный    spread     обычный
//      → результат: ["prefix", "alice", "bob", "suffix"]

Spread на call site можно использовать только для variadic-параметра. Для обычного items []T параметра spread не разрешён — программист передаёт массив явно: f(["a", "b"]).

Семантика

• ...items []T в декларации — это синтаксический marker, не новый тип. Тип items это []T.
• На call site spread ...arr разворачивает arr: []T в позиционные аргументы.
• Без spread’а: компилятор собирает все аргументы в []T неявно (compile-time, zero overhead).
• Только последний параметр может быть variadic — упрощает парсинг и неоднозначности.
• Type checking: каждый аргумент проверяется против element type T; spread-выражение должно иметь тип []T.

Generic-variadic

fn first[T](...items []T) -> Option[T] {
    if items.len() == 0 { None } else { Some(items[0]) }
}

first(1, 2, 3)             // T = int
first("a", "b")            // T = str
first(...["x", "y"])       // T = str через spread

T выводится из элементов или spread-массива.

Heterogeneous-variadic через any

Когда нужен print("count=", 42, " items") (разные типы):

fn print(...items []any) Io -> ()

any — top-type из D54. Каждый элемент конвертируется в строку через str.from(v) (D73). Это разрешает print принимать смешанные типы без T-параметра.

Что НЕ делается

• Variadic не последним параметром (fn f(...xs []int, last str)). Усложняет грамматику без выгоды; в крайнем случае программист переставляет параметры.
• Несколько variadic-параметров — нет смысла.
• Keyword args (Python **kwargs) — отдельная фича, не нужна для variadic use-case.
• Postfix-синтаксис как в Go (items ...string). Префикс ... единый для всех spread’ов в Nova (D60 для массивов, D69 для variadic) — symmetric.
• Element-type как в Go (...items T). Декларация показала бы «items: T» с magic-преобразованием в []T. Nova предпочитает явный array-type без скрытой обёртки.

Почему

1. D60 symmetry. В литералах массивов уже используется prefix ...arr для spread. Variadic-call-spread f(...arr) — та же форма.
2. D40 «один способ». Нет «двух типов в одной декларации» (element vs array как в Go). Тип параметра = []T, конец.
3. TypeScript-прецедент. Самый популярный variadic-синтаксис в современных языках, LLM знает.
4. AI-friendly. Сигнатура (...items []T) сразу показывает:
   • ... → variadic;
   • []T → точный тип параметра;
   • element type выводится естественно.
5. Минимальные изменения грамматики. Парсер уже распознаёт ... в spread-литералах (D60). Расширение на параметры функции — маленькое дополнение.

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

• Без variadic вообще (всегда явный f([a, b, c])). Отвергнуто: частые отладочные print(...) стали бы шумнее. Variadic — конкретное улучшение DX.
• Macro-style (println!-как-в-Rust). Отвергнуто: у Nova нет macro-системы; добавлять её только ради variadic — overkill.
• Variadic через Java-style autoboxing (Object...). Отвергнуто: no implicit boxing в Nova; используем any явно.

Связь

• D60 — spread ...arr в литералах массивов и record’ов; D69 распространяет на параметры функций.
• D54 — any для heterogeneous-variadic.
• D27 — []T как тип параметра.
• 08-runtime.md → D26 — print/println теперь имеют сигнатуру fn print(...items []any) Io -> ().

Эволюция

Bootstrap-stdlib изначально имел print как Native-функцию принимающую переменное число аргументов (Rust-side &[Value]), но в спеке D26 определял fn print(s str) — fixed arity 1. Это был drift между implementation и spec.

D69 фиксирует variadic как полноценную фичу языка и приводит сигнатуру print к fn print(...items []any) Io -> ().

D83. Keywords строго запрещены как identifier’ы

Что

Зарезервированные слова языка (fn, type, let, mut, if, for, while, in, match, use, import, export, и др.) не могут использоваться как имена переменных, полей, параметров, типов, методов, импортов или любых других user-defined identifier’ов. Никаких escape-механизмов не предусмотрено.

Закрывает Q-keywords-as-fields вариантом 1 (строгий запрет).

Правило

Полный список зарезервированных слов

Декларации: module, import, use, export, external, fn, type, protocol, effect, handler, alias.

Bindings: let, const, mut, ro.

Control flow: if, else, match, for, while, loop, in, return, break, continue.

Effects/concurrency: with, throw, interrupt, forbid, realtime, spawn, supervised, parallel, detach, blocking, select.

Cleanup (D90): defer, errdefer.

Operators (как слова): as, is, and, or, not.

Литералы: true, false.

Test: test.

Special: Self (D66), _ (wildcard / discard).

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

// все следующие — compile error «expected identifier, got keyword `X`»

ro if = 5                          // ✗
mut while = 0                   // ✗

type Queue[T] {
    in []T                          // ✗ — «expected identifier, got `in`»
}

fn process(match int) -> int =>     // ✗ — параметр не может быть `match`
    match * 2

fn export() -> int                  // ✗ — `export` зарезервировано

import std.use                      // ✗ — `use` в module path

Что разрешено

Зарезервированные identifier’ы (D26 prelude — Self, any, never, Option, Some, None, Result, Ok, Err, Error, int, f64, etc.) — это обычные имена в prelude scope, не keyword’ы. Программист может переопределить локально (см. overview.md «Зарезервированные identifier’ы»), но это анти-паттерн (lint выдаёт warning).

ro int_array []int = [1, 2, 3]    // ✓ — `int_array` обычный identifier
fn shadow() {
    ro int = "string"              // ⚠️ shadow's prelude name (warning, не error)
    println(int)
}

Контекстуальные keywords — отвергнуто

Альтернатива из Swift/C# (async, var, dynamic контекстные — keyword только в специфичных позициях, иначе обычные identifier’ы) не принимается в Nova. Все keyword’ы — глобально зарезервированы.

Escape-механизм (r#identifier, `identifier`) — отвергнуто

Альтернативы:

• Rust-style r#fn — raw identifier через r# префикс.
• C#-style @class — verbatim identifier.
• Swift/Kotlin `class` — backticks.

В Nova сейчас не предусмотрены. Программист переименовывает поле/переменную если оно конфликтует с keyword.

Когда может появиться: если накопится боль FFI с C-библиотеками у которых функция называется match, или ORM/JSON-данные с keyword- полями. До v1.0 — не вводим, после v1.0 — отдельный D-decision (вероятно r#identifier Rust-style).

Backtick’и `...` в Nova уже заняты для tagged template literals (D48 raw strings) — Swift-style `identifier` создаст конфликт.

Почему

1. Простота парсера. Один-проход рекурсивного спуска, никакого lookahead’а для разрешения «keyword vs identifier».

2. AI-friendly. LLM никогда не путается между keyword и identifier. Никаких escape-форм для запоминания.

3. Читаемость. Программист видит if — control flow. Видит class — class. Никаких if как имени переменной.

4. Прецедент мейнстрима. Java, Go, C, Python — все строго запрещают. Default ожидание программиста.

5. Future-proof по версии. Без escape — добавление нового keyword’а это явный breaking change, программист видит compile error и переименовывает (как Rust 2018/2021 editions).

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

• Контекстуальные keywords (Swift/C# style). Сложнее парсер, AI-unfriendly. Прецедент Swift: contextual keywords постепенно становятся глобальными.

• r#identifier (Rust-style). Полезен для FFI, но не приоритет в bootstrap’е. Можно добавить позже без breaking change.

• @identifier (C#-style). В Nova @ занято (D35 self-method/field).

• `identifier` (Swift/Kotlin). Backtick’и заняты для raw strings (D48). Конфликт.

• Только-в-полях ослабление (например mut in []T разрешено поскольку in контекстный для for x in iter). Отвергнуто — специальное правило для одного keyword’а нарушает D9.

Связь

• Q-keywords-as-fields — закрывается этим D-decision.
• D29 — module/import grammar.
• D30 — naming convention. D83 — жёсткое правило поверх D30.
• D48 — backtick’и заняты.
• D26 — prelude names — это identifier’ы, не keyword’ы.

Цена

• Sweep std/collections/queue.nv — поле in []T переименовать в input или inputs.
• Будущая FFI работа будет требовать обёртки если C-функция называется так же как Nova-keyword. Не блокер.

Эволюция

До D83 вопрос был open в Q-keywords-as-fields с тремя вариантами. D83 закрывает вопрос окончательно — Java/Go/C/Python style строгий запрет, без escape.

Если когда-либо в будущем (v1.0+) накопится FFI-боль — отдельный D-decision вводящий r#identifier Rust-style. До v1.0 — строгий запрет без escape.

D88. Default-значения generic-параметров

Что

Generic-параметры могут иметь default-значение через [T = Default] или с bound’ом [T Bound = Default]. Default используется когда компилятор не может вывести параметр из аргументов и программист не указал его явно.

Закрывает Q-default-generic. Триггер принятия — D87 (Effect[E, IRT = never]).

Правило

Базовый синтаксис

type Complex[T = f64] {
    re T
    im T
}

// Старые вызовы продолжают работать без [T]:
ro z = Complex.from(2.0)             // T выводится как f64 (из default + arg)
ro z Complex = Complex.new(1.0, 2.0)  // тип Complex без скобок ≡ Complex[f64]

// Новые — с явным параметром:
ro z32 Complex[f32] = Complex.new(1.0_f32, 2.0_f32)

С bound’ом

fn run[T Numeric = int](a T) -> T => a + 1

run(5)                          // T = int (вывод из аргумента)
run(5.0)                        // T = f64 (вывод из аргумента)
run[i64](5)                     // T = i64 (явно)

Грамматика для одного параметра: name [bound] [= default].

Семантика

fn first[T = int](xs []T) -> Option[T] { ... }

first([1, 2, 3])                // T = int (вывод из []int)
first[]([])                     // ERROR: empty array, T не выводится
                                //        default не применяется (тип элемента
                                //        не из argument-type)
first[str]([])                  // T = str (явно)

Несколько параметров

Параметры с default’ом должны идти после обязательных:

type HashMap[K, V, S = DefaultHasher] { ... }       // ✅
type Bad[T = f64, U] { ... }                         // ❌ обязательный после default'а

Все default’ы могут быть опущены частично:

ro m HashMap[str, int] = ...                        // S = DefaultHasher
ro m HashMap[str, int, FxHasher] = ...              // S явно

Default — это тип, не выражение

type X[T = f64] { ... }              // ✅ default = тип
type Y[N = 10] { ... }               // ❌ const-generic — отдельная фича, не входит

В D88 default — только тип. Const-generic (значения как параметры типа) — отдельная задача, не покрывается.

Default через bound

type Sorted[T Ord = int] { ... }        // T должен реализовать Ord; если не указан — int

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

Default-тип должен удовлетворять bound’у — компилятор проверяет это при объявлении.

Почему

1. Backward-compat. Добавление generic к существующему типу/функции = breaking change без default’ов. С default’ами — ноль ломаний:

   // Раньше:
   type Complex { re f64, im f64 }
   
   // Теперь generic, но старый код работает:
   type Complex[T = f64] { re T, im T }
   ro z = Complex.from(2.0)            // ← без правок
   

2. Default — не выбор для программиста. Это сокращённая запись, не два пути с разной семантикой. Нарушения D9 «один очевидный путь» нет — программист либо не пишет параметр (получает default), либо пишет (получает явное значение).
3. Прецеденты: Rust (Vec<T, A: Allocator = Global>), C++ (template<typename T = int>), TypeScript (Foo<T = string>).
4. Realistic consumer. D87 Effect[E, IRT = never] — главный практический use-case в Nova prelude.

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

• [T default int] keyword-форма — длиннее, без выгоды.
• Const-generic в default’е ([N = 10]) — отдельная фича, отложена.
• Forward-references в default’е ([T = SelfType]) — запрет: тип должен быть уже объявлен в момент парсинга generic-списка.
• Default-параметры функции (fn f(x int = 0)) — отдельная задача и отвергнута (history/rejected.md) в пользу опции-record + spread. D88 касается только generic-параметров типа.

Связь

• D16 — синтаксис [T].
• D72 — generic bounds ([T Hash]); D88 расширяет до [T Hash = SomeDefault].
• D52 — newtype/alias; D88 дополняет alias-механику (alias для конкретной инстанции, default — для самой частой).
• D87 — Effect[E, IRT = never] главный consumer.

Эволюция

Зафиксировано 2026-05-10. Раньше — открытый вопрос Q-default-generic, помечен DEFERRED до появления реального consumer’а. Триггер — D87 параметризация Handler interrupt-типом.

Migration: ~10 примеров Effect[E] в spec/, где требуется Effect[E, IRT] для interrupt-делающих handler’ов. См. D87 миграция.

D90. defer и errdefer — scope-level cleanup statement

Закрывает Q20 «Нужен ли defer?».

⚠️ Амендмент (D189 ретракт + D314 defer-kernel): errdefer (и okdefer/defer |result|) РЕТРАКТНУТЫ (D189); парсер отвергает их [D189-removed-*]. Замена — outcome-несущая форма defer(o ScopeOutcome) { … } (D314, Plan 173 Ф.2): тело получает исход Success | Failure(reason) | Panic(msg); errdefer{b} ≡ defer(o){ match o { Failure(_)|Panic(_) => b, Success => () } }. Bounded lookahead различает defer(o ScopeOutcome){…} от defer (expr); defer(o T) с T ≠ ScopeOutcome → [E_DEFER_OUTCOME_TYPE], лишние токены → [E_DEFER_OUTCOME_ARITY]. Секции ниже про errdefer — historical. Плейн defer (п.1) без изменений (byte-identical).

Что

Два keyword-statement’а для отложенного выполнения при выходе из текущего scope’а:

1. defer <body> — выполнить <body> при любом exit’е из enclosing scope (normal flow, return, throw, interrupt, panic).
2. errdefer <body> — выполнить <body> только при exit’е через ошибку (throw/panic). При normal exit или return errdefer не выполняется.

Назначение — детерминированный cleanup (close, unlock, rollback) в языке без RAII-destructor’ов (D6 managed heap — нет detrministic destruction; см. цена D6).

Правило

Грамматика

statement = ...
          | 'defer'    body
          | 'errdefer' body

body = expression
     | block             // { stmt1; stmt2; ... }

body — обычное выражение или block. Никаких params, никаких => — это statement, не closure.

Примеры

Простой defer:

fn read_config(path str) Fs Fail -> Config {
    ro file = Fs.open(path)
    defer file.close()                  // выполнится на exit из fn
    ro raw = file.read_all()
    Config.parse(raw)
}

Block-form:

fn process() Db Log -> () {
    defer {
        Log.info("done processing")
        Metrics.record_completion()
    }
    Db.exec(...)
}

Несколько defer — LIFO (последний defer’нутый — первый выполнится):

fn nested() Fs -> () {
    defer println("3")          // выполнится последним
    defer println("2")
    defer println("1")          // выполнится первым
    // exit prints: 1, 2, 3
}

Scope-level (не function-level):

fn process() Fs Log -> () {
    ro log_file = Fs.open("app.log")
    defer log_file.close()              // выход из fn

    if condition {
        ro temp = Fs.create_temp()
        defer temp.cleanup()            // выход из if-блока
        write_to(temp)
    }   // <- здесь выполняется temp.cleanup()

    // <- здесь выполняется log_file.close() при exit из fn
}

errdefer — откат при ошибке:

fn create_user(data UserData) Fail[Db] Db -> User {
    ro user = Db.insert_user(data)
    errdefer Db.delete_user(user.id)    // откат если что-то дальше упадёт

    ro profile = Db.insert_profile(user, data)
    errdefer Db.delete_profile(profile.id)

    Db.send_welcome(user.email)         // если throw — оба delete сработают
                                         // в LIFO порядке (delete_profile, потом delete_user)

    user                                 // normal exit — errdefer'ы НЕ выполняются
}

Комбинированно — defer + errdefer:

fn transaction() Fail Db -> Receipt {
    Db.begin()
    defer Log.info("transaction finished")    // ВСЕГДА
    errdefer Db.rollback()                     // только при throw

    ro r = do_work()
    Db.commit()
    r
}
// normal exit: Db.commit() → Log.info(...)
// throw exit:  Db.rollback() → Log.info(...)

Семантика

1. Scope-level. defer/errdefer привязаны к enclosing block (function body, if/else branch, for body, with-block, supervised-body, etc.). Выполняются при exit’е именно этого scope’а.

2. LIFO order. Несколько defer’ов выполняются в обратном порядке регистрации (последний defer — первый выполняется).

3. Eager argument evaluation. Аргументы defer-выражения вычисляются в момент defer, тело — откладывается:

ro i = 5
defer println(i)            // i = 5 захвачено сейчас
ro i_new = 100             // другая переменная (immutable)
// exit prints: 5

Для mut-переменной с теми же captures-правилами:

mut counter = 0
defer println(counter)      // counter — захвачен по reference (как closure)
counter = 42
// exit prints: 42

Это симметрично closure-семантике D32 (managed heap, mut-captures through reference).

4. Defer body — Fail-allowed с composition (amended by D158, Plan 100.4.1, 2026-05-23). Тело defer/errdefer может иметь Fail[E]-эффект; cleanup-failure композируется с propagating error через Plan 49 multi-error infrastructure. Enclosing fn-sig обязан declare Fail[E'] с совместимым E ⊆ E'.

fn process() Fail[WorkErr] -> () {
    consume tx = begin()
    defer { tx.commit() }                       // ✅ Fail[CommitErr] body
    do_work()?                                   // throws WorkErr
    // composite: { primary: WorkErr, suppressed: [CommitErr] }
}

Если defer body имеет Fail[E], но enclosing fn-sig не declares Fail — compile error D158-defer-fail-not-in-sig. Это force’ит explicit visibility cleanup-fail в API.

Backward-compat: handler-wrap pattern продолжает работать как opt-in shorthand для silent-suppress:

defer {
    with Fail = handler {
        fail(e) { Log.error("cleanup failed: ${e}"); interrupt () }
    } {
        risky_cleanup()                          // Fail caught в inner with
    }
}

Подробно — composition rules, MultiError API, diagnostic format — D158.

Historical (pre-D158, Plan 20 Ред. 1): body было infallible — любой Fail[E] в defer body выдавал compile error. Programmer обязан был ручной handler-wrap. D158 (Plan 100.4.1) снял это ограничение, сохранив compile-time visibility через required fn-sig Fail[E'] declaration. Скрытого поглощения ошибок по-прежнему нет: cleanup-fail видна either как composite-error caller’у, либо через explicit handler- wrap внутри defer.

5. Defer body — suspend allowed (amended by D159, Plan 100.4.2, 2026-05-23). В теле defer/errdefer разрешены suspend-операции: Time.sleep, Net.*, Fs.*, Db.*, Channel.recv — для production graceful cleanup (socket close с FIN+ACK, DB drain, async commit).

Запрещены только AST-level concurrency constructs: spawn, parallel for, supervised, detach, blocking — они leak supervised hierarchy (новый fiber переживает scope cleanup’а). Это compile error E (D159-spawn-in-defer).

Cancel-safe semantics (D159): runtime обеспечивает что cleanup completes-then-propagates cancel. Programmer должен использовать Time.timeout(d) { ... } (Plan 22) для bounded cleanup.

Historical (pre-D159, Plan 20 Ред. 1): body было no-suspend — любая suspend operation в defer выдавала compile error. Programmer обязан был ручной with Time.timeout обёртка. D159 (Plan 100.4.2) снял ограничение для production-grade async cleanup.

6. Top-level return / break / continue / interrupt в defer-body — запрещены (Вариант 3 — Plan 20 Ф.3 revised). Нельзя hijack scope-exit окружающей функции/цикла через defer — defer сам часть exit-процесса.

Локальный control разрешён, только внутри вложенных конструкций:

• return — разрешён внутри nested fn-литерала в defer body (return локален к этому fn-литералу, не к enclosing fn).
• break / continue — разрешены внутри nested loop (for/while/loop) в defer body (локальны к этому loop’у, не к enclosing).
• interrupt — всегда запрещён на любом уровне (hijack scope-exit с-effect-block’а; не failable cleanup).
• throw / ? / !! — разрешены (D158, Plan 100.4.1) если enclosing fn-sig объявляет Fail[E]; cleanup-fail композируется через Plan 49 multi-error (см. пункт 4 и D158).

defer {
    for x in items {
        if x.bad { break }          // ✅ local break в nested loop
    }
    return 0                         // ❌ top-level return — hijack scope exit
}

defer {
    ro cleanup_fn = || {
        if early_done { return }     // ✅ local return в nested fn-literal
        do_more()
    }
    cleanup_fn()
}

Type-check: DeferBodyCtx { loop_depth, fn_depth } инкрементируется при заходе в nested loop/fn-literal; проверка > 0 на каждом return/break/continue.

7. errdefer запускается на:

• throw err (любой Fail[E]).
• panic(msg) — пока fiber не умер.
• interrupt v — нет, это normal control flow (с точки зрения errdefer scope’а — exit «успешный»).
• exit(code, msg) — нет, exit гасит процесс без cleanup’ов (D13).

8. defer запускается на:

• Normal exit (последнее выражение block’а вычислено).
• return.
• throw err.
• panic(msg) — пока fiber не умер.
• interrupt v — да (exit scope’а, неважно как).
• exit(code, msg) — нет (D13: exit без cleanup’ов).

Почему

Зачем нужен defer в Nova

В Nova нет deterministic destructor’ов (D6: managed heap + GC). RAII Rust/C++ невозможен. Без defer resource cleanup (file.close, unlock, rollback) пишется через handler-блоки с copy-pasted error-paths:

// Без defer — verbose:
fn create_user(data UserData) Fail Db -> User {
    ro user = Db.insert_user(data)
    mut profile_id Option[int] = None
    with Fail = effect Fail {
        fail(e) {
            if Some(pid) = profile_id { Db.delete_profile(pid) }
            Db.delete_user(user.id)
            throw e
        }
    } {
        ro profile = Db.insert_profile(user, data)
        profile_id = Some(profile.id)
        Db.send_welcome(user.email)
    }
    user
}

Десятки строк boilerplate. С defer/errdefer — 6 строк (см. пример выше). Это значительная экономия.

Прецеденты

Nova берёт Zig-style: scope-level + errdefer. Не function-level (Go), потому что Nova имеет вложенные scope’ы с богатой семантикой (if, for, with, supervised) — function-level ограничивал бы. Не D-style scope(success) — редко нужно, можно писать обычным кодом перед exit’ом.

Почему scope-level, не function-level

Function-level (Go) накапливает все defer’ы в стеке функции:

func f() {
    if cond {
        temp := create()
        defer temp.cleanup()        // выполнится в КОНЦЕ func, не на exit if
    }
    long_running_work()              // temp висит всё это время
}

В Nova scope-level позволяет локальный cleanup, что часто естественнее.

Почему eager argument evaluation

Если бы аргументы вычислялись lazy:

mut i = 0
defer println(i)
i = 42
// exit: print 42 (хотел печатать 0?)

Это regular для closure-семантики, но сюрприз для programmer’а ожидающего «defer фиксирует значение тогда же».

Eager arguments + lazy closures (через captures) — баланс. Это путь Go (которому 15 лет программистской практики симпатизируют).

Почему failable body + composition (а не infallible — historical)

Plan 20 Ред. 1 (2026-05-11) выбрал infallible body. D158 (Plan 100.4.1, 2026-05-23) revised к failable + composition. Аргументы.

Допустим, defer-body может падать:

fn process() Fail[CommitErr] -> () {
    consume tx = begin()
    defer { tx.commit() }           // commit may fail
    do_work()?                       // throws WorkErr
    // exit: WorkErr propagating → defer fires → commit throws CommitErr → ???
}

Языки решают по-разному:

• Rust: panic-in-Drop = abort() процесса. Безопасно, но programming совершенно непрактичен — tx.rollback() который может fail = abort.
• Go: defer возвращает error через named return — manual handling, легко пропустить. На практике все игнорируют.
• TS (ES2024) / Java: Symbol.dispose / close() throws → composite SuppressedError / addSuppressed() chain. Структурированно, caller видит весь chain.

Nova D158 выбрал TS/Java-подход: composition через MultiError chain. Plan 49 multi-error infrastructure уже даёт kinded throws + typed payload; D158 добавляет nv_compose_suppressed для chain append’а и MultiError prelude type для caller-side inspection.

Visibility сохранена через fn-sig: enclosing fn-sig обязан declare Fail[E'] где E ⊆ E' для defer body. Без этого — compile error D158-defer-fail-not-in-sig. Это сильнее Go/TS (которые не enforce’ят visibility в сигнатуре), сравнимо с Java checked exceptions, но без их verbosity — Fail[E] уже часть base effect-system.

Backward-compat: handler-wrap pattern сохраняется как opt-in shorthand для silent suppress (см. пункт 4 example).

Почему suspend allowed (а не no-suspend — historical)

Plan 20 Ред. 1 (2026-05-11) запретил suspend в defer body argument’ируя «cleanup быстрый». D159 (Plan 100.4.2, 2026-05-23) revised: production cleanup ОБЯЗАН suspend — graceful socket close с FIN+ACK, DB drain через Channel.recv, async transaction commit. Без suspend programmer вынужден делать leak-y fire-and-forget cleanup.

D159 решение: suspend allowed, но:

• spawn / parallel for / supervised / detach / blocking — запрещены (leak supervised hierarchy: новый fiber переживает scope cleanup’а).
• Programmer отвечает за bounded cleanup через Time.timeout(d) { ... } (Plan 22 sleep-libuv-integration).
• Runtime обеспечивает cancel-safe semantics: cleanup completes before cancel-propagation (production-grade — Plan 100.4.2 followup [M-100.4.2-cancel-shielding] для full runtime enforcement; в bootstrap defer runs after throw, cancel-as-throw тоже triggers cleanup).

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

• Function-level defer (Go-style) — слабее scope-level, ограничивает локальный cleanup.
• successdefer (D scope(success)) — редкий case, обычный код перед exit покрывает.
• defer без errdefer — errdefer критичен для transactions, без него boilerplate тот же что и без defer. Включаем сразу.
• Lazy argument evaluation — surprise factor, eager — стандарт Go/Swift/Zig/D.
• Failable defer body banned-as-such — first revision (Plan 20) запретила Fail в defer body absolutely. Revised D158 (Plan 100.4.1): failable body разрешён с composition через Plan 49 multi-error chain (MultiError); fn-sig обязан declare Fail[E']. См. пункт 4.
• defer return X — нельзя hijack exit-значение через defer.
• recover (Go) — поглощение panic из defer. Сложная семантика, не нужно в Nova (panic — смерть fiber’а, D13).

Связь

• D6 — managed heap без RAII, мотивирует потребность в defer.
• D13 — panic / exit семантика. defer выполняется при panic пока fiber жив; не выполняется при exit (D13: exit гасит процесс без cleanup’ов).
• D22 — closure семантика; defer использует те же mut-capture правила.
• D32 — managed-heap captures, base для defer captures.
• D85 — ?/!!; в теле defer запрещены (требуют Fail, defer body infallible).
• D91 — Channel revision; defer tx.close() — main use-case для defer в concurrency.
• Q20 — закрыто этим D-блоком.

Bootstrap-status

• ✅ Реализовано (Plan 20, 2026-05-11). Все 7 фаз закрыты:

  • Ф.1 Лексер: keyword’ы defer/errdefer (commit 75673d7).
  • Ф.2 Парсер + AST: Stmt::Defer { body }, Stmt::ErrDefer { body } (commit 380b457).
  • Ф.3 Type-checker constraints (revised: Вариант 3, local control разрешён, commit fdb53be + 3faf9f0):
    • throw/?/!!/interrupt/suspend-effects — всегда запрещены.
    • return/break/continue — запрещены только на top-level defer body; внутри nested fn-литерала/loop — разрешены.
  • Ф.4 Codegen: per-scope DeferScope с активационными флагами; NovaFailFrame setjmp wrapper для errdefer throw-path с longjmp re-throw; integration во все emit_block_* paths; early-exit cleanup для return/break/continue (commits 94151c3 + b058968).
  • Ф.5 Interp: per-scope defer-stack, LIFO invocation, errdefer skip non-error exit (commit c96f7f3).
  • Ф.6 Positive-тесты: defer_basic.nv, errdefer_basic.nv, errdefer_throw.nv (interrupt handler).
  • Ф.7 Spec uplift: текущий блок.
  • Ф.8 Production-grade hardening (2026-05-11, commits e04ca85d
    • 61af5af4 + 007bb9ba + d913aa08 + 33c1e050):
    • (1) Type-check enforcement D61 §1430-1434: handler-method для эффект-операции с return type never ОБЯЗАН закончиться interrupt/throw/panic/exit. Static analysis в check_handler_never_ops + helpers (expr_diverges, block_diverges). Покрывает Fail.fail + user-defined effects с never-методами.
    • (2) Defer/errdefer на interrupt-path: codegen эмитит local NovaInterruptFrame setjmp wrapper аналогично fail-frame. На interrupt — invoke только defer (skip errdefer — это handled exit), pop interrupt-frame, re-interrupt с тем же value.
    • (3) Loop/branch body defer integration: while/loop/while-let/ for-in-array/for-in-iter/else-branch/match-arm — все эмитят defer scope (раньше только for-range body был покрыт).
    • (4) D65 правило 3 (re-throw): NovaVtable_Fail.prev = outer handler; Nova_Fail_fail на время handler-body invocation swap’ает _nova_handler_Fail = current->prev, восстанавливает после. Throw в handler-body dispatch’ится на outer (skip current frame — нет infinite recursion).

  Ф.8 positive-тесты:

  • syntax/defer_in_blocks.nv (9 кейсов) — defer внутри while/loop/for-in-array body, else-branch, match-arm-block, nested defer scopes (LIFO между inner/outer).
  • syntax/errdefer_rethrow.nv (3 кейса) — re-throw из inner handler → outer (1-level и 3-level); errdefer + outer interrupt → errdefer корректно skip.
  • syntax/defer_on_interrupt.nv (4 кейса) — defer fires на interrupt-path; errdefer skip; defer+errdefer combo; LIFO для multiple defer’ов.

  Ф.8 negative-тест:

  • negative_capability/fail_handler_no_exit_rejected.nv — handler fail() без exit-control → compile error.

  Все 12 positive + 6 negative defer-relevant тестов PASS. 10/10 effects + 17/17 concurrency без регрессий после Ф.8.

Известные ограничения

• Suspend (Db/Net/Fs/Time/spawn) в defer body — compile error (Ф.3). Это spec-compliant strict ограничение, не gap.
• exit(code, msg) не запускает defer’ы (D13: exit гасит процесс без cleanup’ов) — by design.
• Cleanup на panic(msg) — для bootstrap’а purposefully простой: если fiber жив, defer тоже срабатывает через fail-frame longjmp-path (panic dispatch’ится через nova_throw).

D102. Именованные аргументы и значения параметров по умолчанию

Status: active (spec). Базовая реализация — Plan 46 (закрыт). Ревизия «дефолт → keyword-only» (2026-05-15) — Plan 50. 2026-06-01 D199 amend: default-value expression может вызывать const fn (D199) — call-site replaced литералом во время компиляции, default остаётся Expr::IntLit/StrLit/... после Plan 114.4.2 Ф.3. Plan 114.4.2 fixture const_fn_used_in_const_ok.nv — proof-of-concept с module-level const; default param сценарий — followup-сценарий (parser + checker уже совместимы).

Что

Параметр функции может иметь значение по умолчанию; на месте вызова аргумент может передаваться по имени. Ключевое правило: параметр с дефолтом передаётся только по имени, позиционно — нельзя.

fn connect(host str, port int = 8080, tls bool = false) -> Conn

connect("localhost")                       // ок — обязательный позиционно
connect("localhost", port: 9000)           // ок — дефолтный по имени
connect("localhost", tls: true, port: 80)  // ок — именованные переставимы
connect("localhost", 9000)                 // ОШИБКА — port с дефолтом, только по имени
connect("localhost", 9000, true)           // ОШИБКА — нечитаемые позиционные флаги

Ментальная модель одной строкой: обязательный параметр — позиционно, опциональный — по имени.

Это общая фича языка, не спецсинтаксис. supervised(cancel: tok) (D75) — обычный именованный аргумент.

Правило — объявление

fn f(required int, opt int = 0, flag bool = false)
//   ^^^^^^^^      ^^^^^^^^^^^   ^^^^^^^^^^^^^^^^^
//   без дефолта   с дефолтом    с дефолтом

1. Параметры с дефолтом идут после параметров без дефолта. fn f(x int = 0, y int) — compile error.
2. Default-выражение вычисляется на месте вызова, каждый вызов заново (не Python-style def-time). Может ссылаться на предшествующие параметры и module-level const:

   fn slice(xs []int, from int = 0, to int = xs.len())
   

3. Variadic-параметр (D69) остаётся последним и не может иметь дефолта (его дефолт — пустой пакет). Параметры до variadic могут иметь дефолты.

Правило — вызов

// fn f(required int, opt int = 0, flag bool = false)

f(1)                       // opt, flag опущены → дефолты
f(1, opt: 5)               // дефолтный по имени
f(1, flag: true, opt: 5)   // именованные переставимы
f(required: 1, opt: 5)     // обязательный тоже можно по имени
f(1, 5)                    // ОШИБКА — opt с дефолтом, позиционно нельзя
f(opt: 5, 1)               // ОШИБКА — позиционный после именованного

1. Параметр с дефолтом — keyword-only. Передаётся только по имени; позиционно — compile error. (Исключение — trailing-форма для последнего функционального параметра, см. «Взаимодействие».)
2. Параметр без дефолта связывается позиционно или по имени.
3. Позиционные аргументы идут первыми, связываются слева направо. Именованный аргумент не может предшествовать позиционному — f(opt: 5, 1) — compile error.
4. Именованные аргументы переставимы между собой.
5. Каждый параметр связывается ровно один раз. Передать параметр и позиционно, и по имени — compile error (f(1, required: 2)).
6. Параметр с дефолтом можно опустить; параметр без дефолта — обязателен (позиционно или по имени).
7. Имя в name: expr — это имя параметра callee, не выражение.

Грамматика

param        = ident type [ '=' expr ]
params       = param { ',' param } [ ',' '...' ident '[]' type ]
call-args    = [ pos-args ] [ ',' named-args ] | named-args
pos-args     = expr { ',' expr }
named-args   = named-arg { ',' named-arg }
named-arg    = ident ':' expr

Внутри (...) вызова ident ':' expr всегда именованный аргумент — коллизии с record-литералом нет (record-литерал — Имя { ... } в фигурных скобках, D43). f(User { name: "a" }) — позиционный аргумент-record.

Взаимодействие

• D43 trailing-block / trailing-fn. Trailing-форма связывается с последним функциональным параметром. Trailing-форма синтаксически отлична от позиционного аргумента в (...), поэтому остаётся допустимой даже если этот параметр имеет дефолт — это не «позиционный аргумент дефолтного параметра». Передать тот же параметр и trailing-формой, и именованным аргументом нельзя (правило 5, «связан дважды»).
• D69 variadic. Именованные аргументы — только для параметров до variadic. После ...items именованных аргументов нет.
• Overloading отсутствует — в Nova нет перегрузки функций, поэтому разрешение «какой параметр» однозначно по имени, без type-directed resolution.
• @-методы / protocol-методы — именованные аргументы работают одинаково для свободных функций и методов.

Почему

1. Нечитаемые флаги — compile error, а не «нежелательно». connect("h", false, true) — позиционные bool/int-флаги нечитаемы и это классическая ошибка LLM-генерации. Правило «дефолт → keyword-only» превращает её из стиль-замечания в ошибку компиляции. Для AI-first языка перевод целого класса багов в compile error — прямо по миссии.
2. Одно правило, обучаемая граница. «Обязательный — позиционно, опциональный — по имени». Не нужно решать на каждом вызове, называть или нет; не нужна система двух имён, как в Swift (_ + label). Опциональные параметры — это как раз те, чей порядок не запоминается.
3. Убирает builder/option-struct boilerplate для простых случаев «функция с несколькими опциональными настройками».
4. Включает supervised(cancel: tok) — синтаксис structured concurrency (D75) опирается на эту фичу.
5. Call-site evaluation дефолтов — нет Python-гочи с разделяемым mutable-дефолтом.

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

• Spread аргументов в вызов — f(...record) (record → именованные) и f(..array) (массив → позиционные). Причины: два разных оператора несогласованны; ... уже занят variadic (D69) и spread-в-литералах (D60); позиционный spread тихо ломается при перестановке параметров callee; call-site становится непрозрачным. Бандл связанных параметров выражается option-struct’ом (fn f(host str, opts Opts = Opts{})) или именованными аргументами.
• Python-style def-time вычисление дефолта — mutable-default гоча.
• Все параметры обязательно-именованные (Swift-style, имя обязательно на call-site для каждого параметра) — лишняя церемония для унарных и math-функций (abs(x: -5), add(left: a, right: b)), и делает имя каждого параметра жёстким API. Keyword-only применяется только к параметрам с дефолтом — обязательные остаются позиционными.
• Исключение «если дефолтный параметр один — разрешить позиционно» — отвергнуто: количество дефолтов не показатель риска (один bool-флаг так же нечитаем, как один из трёх); добавление второго дефолтного параметра тихо ломало бы существующие позиционные вызовы (рефакторинг-ловушка); теряется простота «одного правила».
• Per-параметр opt-in в позиционность (Swift _) — добавляет сложность на декларации; пока не нужно. Если math-функции начнут раздражать многословием — вернуться к этому отдельным решением.
• Позиционный аргумент после именованного — неоднозначно, запрещён.

Эволюция

Ревизия (2026-05-15): добавлено правило «параметр с дефолтом — keyword-only на месте вызова». Раньше дефолтный параметр можно было передать и позиционно. Триггер — позиционные bool/int-флаги (connect("h", false, true)) остаются нечитаемыми и частой ошибкой LLM-генерации даже при наличии именованных аргументов; правило делает их compile error. Рассмотрены и отвергнуты: обязательные имена для всех параметров (Swift-style) и исключение для «одного дефолта» (см. «Что отвергнуто»). Реализация ревизии — Plan 50; существующие call-site’ы из Plan 46 с позиционными дефолтными аргументами требуют миграции.

Связь

• D69 — variadic-параметры; variadic несовместим с дефолтом, остаётся последним.
• D60 — spread ...x в литералах; spread-в-вызов (отвергнут здесь) — другая операция.
• D43 — trailing closure связывается с последним функциональным параметром.
• D75 — supervised(cancel: tok) использует именованный аргумент; ревизия D75 зависит от D102.
• Plan 46 — базовая реализация (named args + дефолты), закрыт.
• Plan 50 — реализация ревизии «дефолт → keyword-only».

D108. Map-литерал [k: v]

Status: active (spec). Реализация — Plan 52. (Номера D104-D107 зарезервированы Plan 45.)

Что

Map-литерал [k: v, ...] конструирует HashMap[K, V]. Ключи и значения — выражения, вычисляются в рантайме.

ro m HashMap[int, str]  = [1: "a", 2: "b"]
ro m = [1: "a", 2: "b"]                       // K, V выводятся из литерала
ro a = 10
ro m HashMap[int, str]  = [a: "x", a + 1: "y"]   // ключи — выражения
ro m HashMap[str, bool] = ["has space": true]    // не-идентификаторный str-ключ
ro empty HashMap[int, str] = []               // пустой — тип из контекста

Дополняет map-coercion {field: v} (02-types.md → D55):

• {...} — ключи это статические имена-идентификаторы → HashMap[str, V].
• [k: v] — ключи это выражения (int, переменная, не-идентификаторная строка, computed) → HashMap[K, V].

Правило — синтаксис и парсинг

collection-literal = '[' ( map-body | array-body | (empty) ) ']'
map-body           = expr ':' expr { ',' expr ':' expr } [ ',' ]
array-body         = expr { ',' expr } [ ',' ]              // D27/D38

Парсинг локальный, без type-directed:

1. После [ парсим первое выражение.
2. Следующий токен : → это map-литерал, дальше пары expr : expr.
3. Следующий токен , или ] → это array-литерал (D27/D38).
4. [] (пусто) → array-или-map, разрешается на type-check по ожидаемому типу — ровно как уже работает пустой массив (D38).

Внутри [...] слева от : — выражение, не имя. Коллизии нет: в [] вообще нет понятия «имя поля» (в отличие от record-литерала {}). Первый : вне вложенных ()/[]/{} — разделитель пары.

Правило — типы и coercion

• Тип литерала — HashMap[K, V]; K/V выводятся из ключей/значений либо из ожидаемого типа.
• Key-позиция — D55 «known-target-type position» с ожидаемым типом K; value-позиция — с ожидаемым V. Значит sum-/record-/map-coercion (D55) композируются на ключах и значениях:

  ro m HashMap[str, JsonValue] = ["name": "alice", "age": 30.0]
  // значения: "alice" → Str(...), 30.0 → Num(...)
  

• Все ключи унифицируются в один K, все значения — в один V.

Правило — порядок вычисления

Порядок вычисления зафиксирован нормативно — это улучшение над Go, spec которого оставляет порядок вычисления map-literal expressions неспецифицированным:

• [k1: v1, k2: v2, ...] — пары вычисляются слева направо; внутри каждой пары — сначала ключ, потом значение. Итоговый порядок side-effect’ов: k1, v1, k2, v2, ....
• Этот порядок observable — побочные эффекты в ключах/значениях наблюдаемы именно в нём.

Правило — порядок итерации

HashMap создаваемый литералом — unordered, как Go и Rust. Порядок итерации не специфицирован и может рандомизироваться между запусками программы (Go-стиль, защищает от случайной зависимости от порядка) либо быть устойчивым в пределах процесса (Rust-стиль, per-instance random seed). Конкретная политика — деталь реализации stdlib и может меняться в будущем (например, при переходе на swisstable-implementation).

Это намеренное проектное решение — без него users пишут fragile тесты («первый элемент в map это X»), которые ломаются при изменении load-factor или hash-seed. Если требуется детерминированный порядок — используйте OrderedMap (insertion-order, отдельный тип через FromPairs протокол, Plan 52.1) или явный sort после .entries().

Сравнение:

• Go: random per-iteration (агрессивно ломает reliance) — мы можем выбрать то же
• Rust: random per-instance (стабилен в пределах HashMap, но между HashMap’ами разный)
• TS Map: preserves insertion (но это другая структура — мы для этого даём OrderedMap)

Правило — десугаринг

Map-литерал десугарится сразу в вызовы методов, без промежуточного массива пар:

[k1: v1, k2: v2]
// →
{
    mut _m0 = HashMap[K, V].with_capacity(2)
    ro _ = _m0.insert(k1, v1)
    ro _ = _m0.insert(k2, v2)
    _m0
}

• Пустой ([] в map-позиции) → HashMap[K, V].new().
• Ноль промежуточных объектов на куче — только сам HashMap (подход Rust vec![]: преаллокация + вставки).
• with_capacity(n) несёт контракт «n вставок без rehash» — аргумент это entry-count, не bucket-count (см. Plan 52).
• @insert возвращает Option[V] (старое значение); в десугаринге возврат всегда явно отбрасывается через let _ = ....
• Temp-переменная — _m0, _m1, … (per-scope счётчик): valid ISO C11, без $; вложенные литералы ([1: [10: "x"]]) не конфликтуют именами.
• Дубликаты ключей — last-wins, естественно из семантики @insert. Если два ключа — одинаковые compile-time константы (int/str/bool literal или const), компилятор выдаёт lint-предупреждение «duplicate key — second entry overwrites first» (паритет с go vet и tsc). Произвольные выражения не проверяются.
• Plan 52 Ф.23 — расширяемость через #from_pairs attribute. Десугаринг по умолчанию вызывает HashMap, но если expected type помечен #from_pairs, target меняется на этот тип. User-типы получают support литерала добавив #from_pairs + протокол:
  • static with_capacity(n int) -> Self — предаллоцировать под n записей;
  • mut @insert_new(key K, val V) -> () — вставить новую запись (без возврата; вызывается только если перед парой не было spread);
  • mut @insert(key K, val V) -> Option[V] — вставить с override (возвращает старое значение; вызывается для пар после spread и в самом spread-цикле — т.к. ключ мог уже присутствовать). Итого: #from_pairs обязан реализовывать оба метода. Полный FromPairs[K, V] протокол (с bound-check через Plan 15) — future generalization, не в bootstrap.
• HashMap.from(arr) остаётся как обычный метод для рантайм-массива пар; литерал через него не идёт.

Правило — NaN как ключ (документированный footgun)

Если K — float (f64/f32) и реализует Hash, то [f64.NAN: "x"] синтаксически валиден. Но по IEEE 754 NaN != NaN, поэтому вставленный NaN-ключ невозможно найти обратно — @get(f64.NAN) всегда вернёт None. Rust решает радикально (f64 не реализует Hash + Eq); Go и TS документируют, но не предотвращают. Nova документирует и предупреждает: если ключевое выражение — константа f64.NAN / f32.NAN, компилятор эмитит warning «NaN as map key — inserted key can never be found». Runtime- проверку не вводим (дорого для non-NaN случаев).

Почему [], а не {}

{...} — это record-литерал (D17/D55). { ident: x } неустранимо неоднозначен: ident — имя поля record’а или выражение-ключ? Различить можно только type-directed parsing (Nova отвергает, D43) или JS-гочей ({a:1} — ключ это строка "a", не переменная). Внутри [...] понятия «имя поля» нет — [a: x] однозначно: a — выражение. Прецедент — Swift (словари на [], не {}).

{field: v} всё равно даёт str-keyed map — через map-coercion (D55), для подмножества «ключи это статические идентификаторы». Это не TIMTOWTDI: {} и [] покрывают разные случаи (имя vs выражение).

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

• Map-литерал на {} ({1: "a"}, {[expr]: v}) — 1 не имя поля, {} пришлось бы парсить тремя способами (блок / record / map) с различием по «идентификатор ключ или нет», что молча меняет семантику ({x: v} record vs {x(): v} map). Фрагильно.
• Десугаринг через HashMap.from([(k,v),...]) — строит промежуточный [](K,V) массив + tuple’ы на куче только ради инициализации. Десугарим сразу в with_capacity + @insert.
• [:] как токен пустой мапы (Swift-style) — лишний спецтокен; [] + ожидаемый тип уже однозначно даёт пустую мапу.
• Map-литерал как compiler builtin — HashMap остаётся stdlib-типом на Nova; литерал — чистый сахар, компилятор знает только имена HashMap / with_capacity / @insert, не реализацию.

Связь

• D27 / D38 — array-литерал на []; map-литерал делит с ним скобки, разводится по :.
• D55 — map-coercion ({field: v}); key/value-позиции литерала — D55 known-target-type positions.
• D17 — record-литерал {...}, с которым [] намеренно не конфликтует.
• Plan 52 — реализация D108 + ревизии D55 (map-coercion).

Spread в map-литерале (Plan 55 followup, 2026-05-16)

...m внутри map-литерала разворачивает другую map того же типа:

ro defaults HashMap[str, int] = ["a": 1, "b": 2]
ro m HashMap[str, int] = [...defaults, "c": 3]      // {a:1, b:2, c:3}
ro m HashMap[str, int] = [...defaults, "a": 100]    // {a:100, b:2} (override)
ro m HashMap[str, int] = [...a, ...b]               // merge two maps

Семантика «right-most wins»: при duplicate keys позже встретившаяся запись побеждает (как JS object spread, Python {**a, **b}).

Парсер использует lookahead для disambiguation: [...x, y, z] рассматривается как array, [...x, k: v] — как map. Edge case [...x] (только spread без pairs) — type-directed: если expected тип помечен #from_pairs (HashMap), интерпретируется как map.

Status (bootstrap): parser + desugar + annotator готовы; codegen для [...src] с non-empty src блокирован orthogonal [M-mono-tuple-element-types] (Plan 56 scope). Эффективно работает spread пустых map’ов + pair-only литералов.

Mono invariants (Plan 55 Ф.4, 2026-05-16)

Codegen (emit_c.rs) при monomorphization сохраняет следующие invariants:

1. current_fn_return_ty save/restore в emit_fn через mem::replace + restore в конце. Это предотвращает leak prior return type в recursive emit (mono’d transitively’d deps).
2. Protocol-method return-type whitelist — для well-known protocol methods (eq/ne/lt/le/gt/ge/is_* → bool; hash → int) infer возвращает stable тип до fallback на fn_ret_<m> lookup (который может содержать stale из другой fn).
3. Placeholder mono skip — register_mono_method_instance + drain_generic_type_worklist отвергают type_subst содержащий Nova_<G>* placeholders (G ∈ fn.generics). Это предотвращает broken erased generic emit для recursive generic calls (e.g. HashMap[K,V].with_capacity внутри HashMap.clone() body).
4. current_type_subst save/restore в local scope — каждая recursive mono call имеет свой subst stack, не leak глобально.
5. Pattern::Record bindings — collect_pattern_inner_bindings для record-form variant patterns (Slot.Occupied { key: k }) использует record_variant_field_types map с lookup mono’d sum_name first, fallback на base. Это предотвращает leak stale var_types между mono’d instances.

Полное описание — Plan 55 Ф.0-Ф.6.

D104. Синтаксис doc-comment’ов — /// outer, //! inner

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

Cross-refs: D101 (#doc "..." module-attr сосуществует с //!); D105 (#doc(...) типизированные атрибуты делят namespace #doc); D106 (code-блоки внутри doc-comment’ов).

Что

Два префикса doc-comment’ов:

• /// — внешний doc-comment (outer): привязывается к следующей декларации (function, type, constant, effect, handler, protocol) — и, с rev-2 (амендмент ниже), к следующему полю записи и следующему варианту суммы.
• //! — внутренний doc-comment (inner): привязывается к окружающему модулю/файлу. Допустим только в начале файла (после строки module X и любых строк import), до первой декларации.

Голое // остаётся обычным комментарием (doc-token не эмитится).

//! Краткое описание модуля.
//!
//! Подробное описание того, что предоставляет модуль, включая
//! примеры, охватывающие несколько items.

module std.example

import std.io

/// Возвращает модуль числа `x`.
///
/// # Examples
///
/// ```nova
/// assert(abs(-5) == 5)
/// ```
fn abs(x int) -> int =>
    if x < 0 { -x } else { x }

Правила

1. Outer (///) — привязывается к следующей декларации в порядке исходника. Подряд идущие /// строки сливаются в один doc-блок. Пустая /// строка не разрывает блок (становится пустой строкой в content); не-doc строка завершает блок.

2. Inner (//!) — допустим только в начале модуля: после строки module <path> и любых import statement’ов, но до первой декларации item’а. Подряд идущие //! строки сливаются.

3. //// (четыре или больше слэшей) — обычный комментарий, не doc-comment. Это копирует поведение rustdoc и предотвращает случайное doc-promotion для идиомы section-divider’ов (//// SECTION).

4. Multi-line merging — подряд идущие /// (или //!) строки без разделяющих blank-строк или других токенов конкатенируются с \n-разделителями. С каждой строки снимается префикс /// (или //!) плюс ровно один опциональный ведущий пробел:

   /// Первая строка.
   ///
   /// Третья строка (после пустой doc-строки).
   

   даёт content "Первая строка.\n\nТретья строка (после пустой doc-строки).".

5. Indentation stripping — когда doc-блок занимает несколько строк, общий leading whitespace (после префикса //////! + одного опционального пробела) снимается единообразно с каждой непустой строки. Это нормализует индентацию markdown:

       /// Indented doc:
       ///   inner detail
   

   даёт "Indented doc:\n inner detail" (четырёхпробельный внешний отступ снят равномерно; двухпробельный внутренний — сохранён).

6. Doc не допускается на module, import, let на module-scope, test-блоке. Документация уровня модуля — через //! (inner doc) или через #doc "..." module-attr (D101); у test-блока doc- convention нет (если нужен комментарий — обычный //).

7. Пустой doc-блок (/// за которым blank line или ///\n) — warning, обрабатывается как отсутствие документации. Style guide запрещает пустые doc-блоки кроме явных случаев #hide_doc (D105).

Amended (D104 rev-2, владелец 2026-08-15, поднято окном плана 274 — novac документирует каждый тип и поле, а язык отвергал /// на поле): поля записей и варианты сумм — носители outer doc.

1. Носители п.1 расширены: outer /// привязывается также к следующему полю записи и следующему варианту суммы. Форма — как у деклараций (Rust): /// строкой выше элемента, привязка «к следующему элементу».

2. Вторая форма — trailing doc (решение владельца расширено 2026-08-15): outer ///, стоящий на ТОЙ ЖЕ строке ПОСЛЕ объявления поля или варианта, привязывается к этому полю/варианту — для коротких описаний:

   type Span {
       lo int /// start offset, inclusive
       hi int /// end offset, exclusive
   }
   type DefKind enum
       | DefType    /// a type declaration
       | DefVariant /// a sum variant
   

   Обе формы законны. Обе формы на одном элементе (строка выше И хвост) — ошибка E_DOC_BOTH_FORMS, не молчаливая конкатенация. Trailing-форма — ТОЛЬКО для полей и вариантов; на декларациях (fn/type/…) хвостовой /// не вводится: это ошибка E_DOC_TRAILING_ON_DECL (до rev-2 такой /// молча уезжал doc’ом к СЛЕДУЮЩЕЙ декларации — та же молчаливая перепривязка, которую запрещает E_DOC_BOTH_FORMS).

3. Слияние (п.4) и снятие индентации (п.5) действуют для полей и вариантов без изменений. //// — по-прежнему не doc (п.3).

4. Висячий /// перед } записи (без поля за ним) — warning как в п.7, не ошибка. У многострочной суммы закрывающего токена нет: /// после последнего варианта — не висячий, а outer doc следующей декларации (привязка «к следующему элементу» без изменений).

5. П.6 (где doc не допускается) — без изменений.

6. Потребители: LSP hover/outline поля и варианта показывают их doc — из любой из двух форм — как у декларации; nova doc рендерит doc поля/варианта в таблице типа.

/// A half-open byte range.
type Span {
    /// Start offset, inclusive.
    lo int
    /// End offset, exclusive.
    hi int
}

/// What a name is.
type DefKind enum
    /// A type declaration.
    | DefType
    /// A sum variant.
    | DefVariant

Position rules — примеры

//! ok: в начале модуля, после module + imports.

module foo

import bar

//! WARNING: //! после первого item — отбрасывается с warning'ом.

/// ok: outer doc на item ниже.
fn baz() -> int => 1

/// orphan outer doc — warning: за ним нет item'а.

fn outer() -> int {
    //! ERROR: //! внутри тела функции недопустим.

    /// ERROR: outer doc на let-statement не поддерживается.
    ro x = 1
    x
}

Кодировка и escapes

• Content doc-comment’а — сырой текст (CommonMark markdown слой применяется позже, в D106 / Plan 45 Ф.5).
• На уровне лексера escape-последовательности не интерпретируются. Backslash’ы, backtick’и и пр. — часть raw content.
• Только UTF-8. BOM в начале файла снимается перед doc-recognition.
• Trailing whitespace на каждой строке сохраняется (от него зависит markdown line-break семантика).

Грамматика на уровне лексера

doc-outer-line  = "///" [content-char ...] NEWLINE
doc-inner-line  = "//!" [content-char ...] NEWLINE
doc-block-outer = doc-outer-line { doc-outer-line }
doc-block-inner = doc-inner-line { doc-inner-line }
content-char    = любой символ, кроме NEWLINE; при этом строка НЕ
                  ДОЛЖНА начинаться с `/` сразу после префикса (т.е.
                  `////` — обычный комментарий, а не doc-prefix + лишний
                  слэш).

Сосуществование с #doc "..." (D101)

D101 определяет атрибут module-level #doc "...", который может стоять перед строкой module X в _module.nv и пропагируется на все peer-файлы. Это комплементарно к //!:

• #doc "..." — для коротких summary модуля, особенно в folder-module’ах с _module.nv.
• //! — для длинной документации модуля в одном каноническом файле, включая markdown-тело и # Examples-секции.

Модуль может иметь оба одновременно. Если оба присутствуют:

• Текст #doc становится module summary (первое предложение).
• Тело //! добавляется как module description.

nova doc склеивает их; конфликта нет, но lint redundant-module-doc предупреждает, если оба содержат идентичный текст.

Почему

1. /// + //! — копирует rustdoc-конвенцию, знакомую широкому developer-сообществу. Заимствование устоявшейся конвенции снижает friction для новичков и AI-ассистентов.
2. //// отвергнут как doc — сохраняет идиому headings-as-comment’ы (//// SECTION) без случайного doc-promotion. rustdoc сделал этот выбор; мы повторяем.
3. Никаких /** ... */-style блочных doc-comment’ов — в Nova вообще нет блочных комментариев (только // line по существующей языковой конвенции). Добавлять блочные doc-comment’ы только ради документации — вводить новый синтаксис комментариев для одной цели.
4. Английский как рекомендованная convention — для широкого охвата и AI/LLM-consumption Plan 45 §11.5 рекомендует писать doc-content на английском. Однако технически lexer/codegen не ограничивают язык — content treated как opaque UTF-8 text, и при необходимости разработчик/команда выбирает язык под свою аудиторию.

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

• /// для inner-doc через position next-line — неоднозначно с привязкой к следующему item’у. Отвергнуто; //! однозначно inner.
• //* ... */-блочные doc-comment’ы — добавляет вариант синтаксиса комментариев для одной цели; line-форма покрывает все случаи одним правилом.
• Авто-promotion // обычных комментариев в doc, когда они предшествуют exported item — неявно и неожиданно. Doc-promotion обязан быть явным (///).
• Doc на import — import’ы не часть public API surface, в output’е не рендерятся.

Связь

• D101 — module-level #doc attribute; правила сосуществования выше.
• D105 — типизированные doc- атрибуты, включая #doc(summary = "...").
• D106 — code-блоки внутри doc-comment’ов являются doc-test’ами.
• D107 — JSON output включает сырой doc-content плюс распарсенную структуру.
• Plan 45 — реализация; §11.5 style guide.

D117. Size-like accessors require call syntax

Status: active (spec). Реализация — Plan 60. (Номера D112–D116 заняты другими планами 33.x.)

AMEND (2026-07-06, решение владельца) — методы-свойства как ОБЩИЙ канон доступа к полям. Правило D117 обобщается со «size-подобных» на ВСЕ поля публичной поверхности типа: канонический доступ — одноимённые методы-свойства через перегрузку по арности (D84): чтение @x() -> T, запись mut @x(v T) -> @ (беглая; возврат приёмника автоматический — D409). Пары get_x/set_x — НЕ канон (в std их 0 — норма уже соблюдена). Прецедент пары: @cap()/@cap(n) (vec/core.nv, исходный D117-амендмент про write-setter). with_x(v) — ДРУГАЯ операция (копия с заменой поля, не мутация; см. nv-coding-style «Именование»). Весь новый код std пишется в этой парадигме.

AMEND-2 (2026-07-06, решение владельца) — сеттер возвращает @. Метод установки свойства по умолчанию объявляется -> @ (беглая форма): это бесплатно (возврат приёмника автоматический — D409, в теле ни строки) и любая последовательность установок становится цепочкой. -> () у сеттера — отступление, допустимое только с обоснованием; установка, которая может отказать (валидация), — не сеттер-свойство, а операция с Result/эффектом.

Что

Для любого типа T методы, возвращающие размер/cardinality/ capacity (len, cap, byte_len, is_empty, плюс будущие count, size если они появятся как built-in convention), вызываются только через method-call с круглыми скобками: t.method().

Запись t.method (без скобок, без @) — это обращение к полю (если поле public), либо compile error если поле не существует. Bound method value (t.@method) удалён в Plan 132 — используй лямбду || t.method() или unbound Type.@method. В подавляющем большинстве случаев голое v.len — user error (забытые скобки).

Правило

ro v = [1, 2, 3]
ro n = v.len()        // ✓ корректно
ro m = v.len          // ✗ error E_SIZE_ACCESSOR_FIELD
ro z = v.is_empty()   // ✓
ro c = v.cap()        // ✓ канон (D117 AMEND 2026-07-06 — Go-style короткое имя;
                       //     `.capacity()` был дублирующим alias, РЕТРАКТИРОВАН
                       //     [M-unwrap-twins-retraction] 2026-07-07)

Что попадает под D117 (по conventional имени):

Имя cap — канон (D117 AMEND 2026-07-06). Прежний дублирующий capacity accessor РЕТРАКТИРОВАН на всех носителях ([M-unwrap-twins-retraction], 2026-07-07) — diagnostic при попытке field-access t.cap (без скобок) подсказывает rename на .cap().

Diagnostic при нарушении

error[E_SIZE_ACCESSOR_FIELD]: size-like accessor `len` is method-only
                              (Plan 60 / D117)
  --> file.nv:42:23
   |
42 |     println("${vec.len}")
   |                    ^^^ help: append `()` — use `.len()` method call
   |
   = note: bare `.len` without `()` — missing parens (bound method value
           syntax was removed in Plan 132; use `.len()` to call)

Для bare .cap (без скобок):

   = help: append `()` — use `.cap()` method call (D117 AMEND 2026-07-06)

Почему

1. Predictable cost. Nova сознательно отвергает TS/Swift-style computed properties (без скобок) — это спрятало бы O(n) операции за field-syntax (например, s.len для UTF-8 string требует codepoint count, O(n)). Скобки везде = «здесь происходит вычисление, возможно дорогое».
2. Consistency. Без D117 — built-in коллекции ([]T, str) дают .len field-style, а user-defined (HashMap, Set) — .len() method-style. Это паттерн Java (arr.length field vs list.size() method), worst-of-both: программист и LLM не могут запомнить «для какого типа какая форма».
3. AI-friendly. D117 — explicit spec’ed contract. LLM, читающий spec, имеет однозначный сигнал. Rust имеет тот же result, но через implicit convention (rustc не выдаёт error если вы определите публичное поле len — Nova выдаёт).
4. Internal C-поля сохранены. arr->len/arr->cap в C-runtime остаются — это implementation detail. arr.len() lowers в zero-cost (arr->len); никакого function-call overhead.

Соответствие state-of-the-art

Nova = Rust паритет, + explicit D-block (Rust полагается на convention без compiler enforcement).

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

• Field-style для всех типов — невыразимо для user-types (encapsulation: HashMap внутри _count + invariant’ы).
• TS/Swift-style property (no parens) — противоречит D14 «скобки обязательны для вызова» и главное — спрячет O(n) операции за field-syntax.
• len(x) builtin (Go-style) — global-function-namespace конфликт с user-types; не работает с method-chaining vec.map(f).len().
• cap() (Go naming) — отвергнуто; полное слово capacity() СУПЕРСЕДЕД D117 AMEND (2026-07-06): cap() стал каноном — precedent-пара read/write свойства @cap()/@cap(n) (см. AMEND-блок выше); capacity() был оставлен как alias, затем сам ретрактирован как дубль ([M-unwrap-twins-retraction], 2026-07-07). Историческая причина отказа (D29 explicitness) уступила единообразию read/write-пары одним именем.
• Allow bare .len как warning, не error — отвергнуто для bootstrap; method-value form требует явного intent (Plan 11 syntax).

Amend (Plan 139.2 Ф.1): self-field carve-out для declaring type-method

E_SIZE_ACCESSOR_FIELD нацелен на внешних caller’ов (s.len, vec.len без скобок — забытые скобки / попытка обойти O(n)-cost сигнал). Метод самого типа имеет полное право читать своё backing- поле напрямую — это implementation detail (см. «Почему» §4: внутренние C-поля сохранены). Для generic-типов (Vec[T] @len() => @len) это уже работало de-facto: при эмите generic-шаблона nova_self-тип ещё не concrete, поэтому guard не срабатывал.

Когда str стал concrete value-record lang-item (Plan 139.1, type str value priv { ptr *u8, len int }), его собственный @len/@byte_len Nova-body (=> @len) начал спотыкаться о D117: infer_expr_c_type(SelfAccess) == "nova_str" + name == "len". Carve- out: bare @len field-read разрешён iff (a) obj — SelfAccess, (b) enclosing receiver — str, (c) name — реально объявленное поле len (НЕ is_empty/cap/byte_len/capacity — они не поля str, остаются method-only даже на @). Внешний s.len (obj — Ident, не SelfAccess) по-прежнему E_SIZE_ACCESSOR_FIELD (regression-проверено: plan60/f3_str_field_rejected, plan139/neg_t0_str_len_field — PASS как negatives).

Это разблокировало миграцию str @len/@byte_at external-C → Nova-body (Plan 139.2 Ф.1): @len() => @len (O(1) byte-len, бывший nova_str_byte_len), @byte_at(i) = bounds-check + unsafe { @ptr[i] } (бывший nova_str_byte_at, идентичная OOB-паника).

Связь

• D32 — array layout (ptr, len, cap); D117 скрывает эти поля от user-language.
• D26 — prelude API; D117 добавляет методы []T.len(), []T.cap(), []T.is_empty(), str.is_empty() в список prelude-API.
• D38 — built-in API для []T; D117 amend’ит таблицу (раздел “Built-in API”).
• Plan 11 — method-value semantics; bound form (x.@len) removed in Plan 132; unbound Type.@method and lambda remain.
• Plan 37 — refine arg-position vs non-arg method-value disambiguation (post-Plan 60 follow-up).
• Plan 45 — stdlib doc-comments обновлены на consistent .len() form.
• Plan 56 — bound-K vtable dispatch для size-accessors на erased generics.

D126. external type — opaque типы без body

Status: 🔴 RETRACTED 2026-06-01 (Plan 91.12 V2) для plain form (external type X без consume).

Retract rationale:

Все 5 stdlib D126 типов мигрированы на более чистые альтернативы:

Тип	Migration	Pattern
StringBuilder	Plan 109 (D179)	Pure Nova consume record { mut buf []u8 }
WriteBuffer	Plan 91.12 V1	Pure Nova record { mut buf []u8 } (consume @into)
ReadBuffer	Plan 91.12 V1	Pure Nova cursor { ro data, mut pos }
OnceCell[T]	Plan 91.12 V2	Tuple-newtype type OnceCell[T](ptr) (Plan 115 D214)
Lazy[T]	Plan 91.12 V2	Tuple-newtype type Lazy[T](ptr) (Plan 115 D214)
Condvar	Plan 91.12 V2	Tuple-newtype type Condvar(ptr) (Plan 115 D214)

Plain external type X declarations в любом модуле теперь — hard error [E_EXTERNAL_TYPE_RETRACTED]. Type-checker emit’ит diagnostic с migration hint:

[E_EXTERNAL_TYPE_RETRACTED] `external type` (D126) retracted by Plan 91.12 V2
(2026-06-01). Replace `external type X` with `type X(ptr)` (tuple-newtype
opaque-handle pattern, Plan 115 D214). C runtime backing preserved через
`external fn` методы — ABI unchanged.
Migration guide: docs/dev/migration/d126-to-tuple-newtype.md.
For FFI opaque consume-types оставайся на `external type X consume` (D163,
supported).

D163 (FFI opaque consume-types) сохраняется: external type X consume остаётся allowed для FFI resource handles (File consume, Mutex consume, etc) — это by-design (D163), Plan 100.5. Только plain (non-consume) form retracted.

Историческая справка: D126 был bridge bootstrap для opaque runtime types (Plan 62.D.bis, 2026-05-18). Через год эксплуатации стало ясно, что эта форма не нужна:

• Для пользовательских FFI handles → D214 type X(ptr) tuple-newtype (Plan 115, 2026-06-01) даёт лучший type-safety + zero-overhead opaque-pointer wrap.
• Для stdlib runtime-backed generic types → тот же D214 паттерн + compiler special-case routing к existing emit_*_instance helpers (Plan 91.12 V2 §«codegen routing»).
• Для FFI resource handles с auto-cleanup → D163 external type X consume (Plan 100.5) — уже отдельная форма с правильной семантикой.

Реализация:

• Plan 62.D.bis (2026-05-18) — D126 introduce.
• Plan 109 D179 (~2026-05-28) — StringBuilder pure Nova migration.
• Plan 91.12 V1 (2026-06-01) — WriteBuffer/ReadBuffer pure Nova.
• Plan 91.12 V2 (2026-06-01) — OnceCell/Lazy/Condvar tuple-newtype + formal D126 retract notice (this §).

Cross-ref: D214 — ptr type + tuple-newtype opaque-handle (Plan 115), D163 — FFI consume integration (Plan 100.5).