Realtime and Performance¶
Accepted
Accepted V1 policy boundary. Checked realtime enforcement is deferred.
Realtime suitability is a core language goal. Catalyst should be usable for audio plugins, DSP kernels, realtime simulation, and other low-latency systems.
Realtime Constraints¶
Realtime-sensitive code needs operational costs to stay visible:
- allocation
- IO
- blocking
- locks
- hidden dispatch
- hidden runtime behavior
V1 models capabilities through ordinary parameters and explicit APIs. Shared capabilities may be grouped in ordinary structs by convention and destructured by functions that need specific fields:
fn process(buffer: []f32) void {
}
fn load({ fs, alloc }: *const IoContext, path: Path) []u8!LoadError {
}
V1 policy
There is no special no-dependency marker and no dedicated allocation/realtime restriction metadata in V1.
Realtime suitability is assessed by inspecting ordinary signatures, resolved calls, parameters, explicit allocator/API use, and the SIR/IR structure already needed by accepted V1 semantics. A function intended for realtime use should not receive or call through allocation, IO, blocking, locking, or hidden-dispatch APIs unless the relevant project policy permits it.
Not V1 semantics
Dedicated realtime attributes such as @realtime, @noalloc, or @kernel, checked realtime regions, allocation-effect metadata, and a separate effect system are not part of the V1 semantic model.
Future enforcement and restriction metadata are tracked by CEP-0020: Realtime Enforcement Regions.
Compiler Role¶
The V1 compiler preserves enough ordinary structure for later tooling to ask:
- does this function allocate?
- can this function block?
- does this function touch IO?
- does this call use a forbidden dependency?
- does this generated IR expose the ordinary calls and dispatch forms that a tool needs to inspect?
These questions are not hard V1 diagnostics and do not require dedicated V1 restriction metadata. Checked answers for regions or declarations belong to future tooling, lint policy, or CEP-0020.