API Reference Guide
The generated API reference is API Reference. It is generated from
checked .0x0 source files by tools/docgen.0x0.
How To Read A Function Entry
Each generated entry currently includes:
- source module path;
- module name;
- function name;
- source type annotation when present;
- source
docannotation when present.
Example shape:
### `option-some`
Type: `(∷ (→ Any Any))`
Create a present optional value.
API Documentation Standard
For public functions, maintainers should make the source doc annotation precise
enough that generated docs can answer:
- purpose: what problem the function solves;
- parameters: expected shape and accepted values;
- return value: exact result shape;
- errors: panic behavior, failed
Result, stable diagnostic, or `Needs
verification`;
- side effects: host effects, capability requirements, filesystem/process/network
behavior, or none;
- preconditions: required argument invariants;
- postconditions: guarantees after success;
- complexity: only when measured or directly obvious from implementation;
- concurrency: actor/runtime/thread-safety behavior when relevant;
- security: path, capability, signing, hardware, or host-boundary constraints;
- example usage: small source form or command when available.
Do not invent fields that the implementation does not provide. Use `Needs
verification` for unproven error behavior, complexity, or concurrency claims.
Current Gap
The generated reference is useful for discovery, but it is not yet Rust-level API
documentation for every public function. Many source annotations are concise.
Needs verification:
- which functions are public APIs versus internal implementation helpers;
- which public functions need expanded
docannotations; - which modules need examples in generated or companion docs.
Updating API Docs
After changing public doc annotations in .0x0 source:
make docs-api
make docs-check
If behavior changed, also update the relevant beginner guide, exact reference
doc, and ADR/RFC documentation impact review.