Orkuncakilkaya
c7c8e2779c
RFC decision (the split the issue recommended): programmer bugs abort loud and located; recoverable failures become values. This ships the first half. panic(msg) prints `file:line: panic: <msg>` to stderr and aborts the process with exit code 1 — a clear, located error instead of a segfault or a silent wrong result. assert(cond, msg) is the guarded form: it aborts with `file:line: assertion failed: <msg>` only when cond is false, otherwise execution continues. The location is baked in at compile time (the call node carries its source line, g_src_name carries the file); the message is any string. Both lower in emit_call to an fprintf-to-stderr + exit(1) + unreachable tail (assert branches on the condition first). @fprintf and the format constant are declared on demand (g_uses_panic), so a program that never panics is unchanged — and the compiler's own source uses neither, so the C-free bootstrap fixpoint holds. - panic/assert registered as builtins across the vocabulary (ludic_syntax.h, the JetBrains lexer, the TextMate grammar) and documented (docs/language/builtins/) - examples/library/errors.ludic covers the success path (asserts hold, program runs to the end); a panic_case in the suite covers the failure path (non-zero exit + the located stderr message). x test is now 69 checks. Deferred: recoverable failures as `try`/`else` values (needs the tagged-union type system, #1) and a top-level `recover` for the dev game loop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
---
|
|
id: fn-assert
|
|
name: assert
|
|
category: builtins
|
|
kind: builtin
|
|
tokens: assert
|
|
sig: assert(cond: bool, msg: string)
|
|
tip: Abort with a located message when an invariant is false.
|
|
order: 11
|
|
---
|
|
|
|
When <code>cond</code> is false, prints <code>file:line: assertion failed: <msg></code> to standard error and aborts (exit code 1); when it is true, execution continues. It is the guarded form of <a href="fn-panic"><code>panic</code></a> — for the programmer-bug cases the language should catch loudly rather than let corrupt the world: an index that must be in range, a value that must be non-negative, a state that must hold before a step. The location is baked in at compile time, so a failure points at the exact assertion. Assertions document and enforce the invariants a system relies on; keep them for "this must be true" checks, not for recoverable runtime conditions.
|
|
|
|
Parameters:
|
|
- `cond` — the invariant that must hold (a bool)
|
|
- `msg` — a message describing the invariant (a string)
|
|
|
|
```ludic
|
|
program Demo {
|
|
function withdraw(balance: int, amount: int) -> int {
|
|
assert(amount >= 0, "amount must be non-negative")
|
|
assert(amount <= balance, "cannot overdraw")
|
|
return balance - amount
|
|
}
|
|
entry {
|
|
print(withdraw(100, 30)) # 70
|
|
print(withdraw(100, 250)) # aborts: Demo.ludic:4: assertion failed: cannot overdraw
|
|
}
|
|
}
|
|
```
|