0.1 Normative terms
| Term | Meaning |
|---|---|
| MUST / SHALL | requirement; a violation is non-conformance to the standard |
| MUST NOT | prohibition |
| SHOULD | recommendation; a deviation is allowed when justified |
| MAY | permission, the behaviour is optional |
| compile error | the implementation SHALL reject the program with a diagnostic |
| warning | the implementation MUST emit a diagnostic and MAY continue |
| panic | an unrecoverable failure of a task (§6.6) |
| implementation-defined | the implementation MUST document its choice |
There is no undefined behaviour in safe code. It is possible only inside unsafe blocks and in FFI (§16).
"Implementation-defined" items. Each such item is marked in the text with an Implementation-defined note that has a stable anchor impl-… and a reference to the decision (D-id) and to the entry of the divergence register (DIV, docs/divergences.md); all items are collected in appendix D together with the choice of this implementation — this is the documentation that the table above requires. Two cases are distinguished:
- behaviour defined by the implementation — the Standard allows several variants, the implementation chooses one and documents it (for example, the borrow-checking rule, §7.2);
- optional feature — a part of the Standard that an implementation MAY leave unsupported (for example, QUIC, §13.1). The implementation MUST document what it does not support and MUST NOT silently replace the feature with different behaviour. A program that uses an unsupported feature is not required to compile or run on such an implementation.
See also
Source: docs/spec/oxl-standard.en.md