Status: sketch | experimental | candidate | stable | rejected Date: YYYY-MM-DD Author: BDFL decision:
What real programmer, compiler, agent, safety, performance, or pedagogy problem does this solve?
Describe the change in one page or less.
Show Hum before and after.
// before
// after
How would this be taught to someone who knows English but not programming?
What does this make explicit that senior engineers already reason about?
What nodes, edges, fields, or diagnostics are added?
What error messages or warnings does this need?
How does this affect syntax highlighting, Tree-sitter, LSP, debugger stepping, source maps, profiler output, and agent semantic graph consumption?
How should canonical Hum format this feature?
What can go wrong? What does this hide or reveal?
Which old language regret does this avoid? Which old language regret could it recreate? What tool catches misuse before it becomes culture?
If this adds syntax, an operator, or a convenience path, what repetition does it
remove, what meaning might it hide, and how do humfmt, chirp, and the
semantic graph keep it honest?
What does this cost? Can it support cost:, benchmarks:, or static checks?
If this touches algorithms, data structures, memory layout, compile-time optimization, or standard-library behavior, what research, benchmark, fallback, and adversarial evidence supports it?
What evidence must exist before this can stabilize?
How will agents understand, edit, repair, and explain this feature?
Does this break anything? How does code migrate?
List serious alternatives and why they lost.
What remains uncertain?
Final taste and direction note.