CEP-0025: Compiler Intrinsic Expression Syntax¶
Draft
Draft proposal for builtin or compiler-intrinsic expression syntax. V1 commits @ to attributes and does not add builtin expression syntax.
Summary¶
Catalyst should eventually decide whether compiler intrinsics need dedicated expression syntax and, if so, what spelling they use.
V1 exposes compiler capabilities through ordinary names, attributes, reflection APIs, and prelude/compiler-provided declarations rather than special builtin expression syntax.
Example¶
Possible future shapes:
const addr = compiler.intrinsic.address_of(value)
const addr = #address_of(value)
The proposal should decide whether low-level compiler operations stay ordinary names or need dedicated expression syntax. @address_of(value) would collide with the V1 meaning of @ as attribute syntax.
Motivation¶
Some low-level operations may be awkward as ordinary declarations if they need direct compiler recognition, target-specific lowering, or syntax-level placement. At the same time, Catalyst should avoid growing a parallel builtin language.
The @ sigil is already attribute syntax in V1, so builtin syntax should not casually reuse it without reopening that tradeoff.
Proposed Direction¶
The proposal should cover:
- whether compiler intrinsics are ordinary prelude/compiler namespace declarations or special syntax;
- whether any syntax marker is needed;
- how intrinsic calls are reflected in diagnostics and docs;
- how intrinsics participate in comptime, safety modes, and target lowering;
- how intrinsic names avoid collisions with user declarations.
V1 Compatibility¶
V1 has no builtin expression syntax. Existing low-level operations should be documented through their owning language or prelude surface.