Skip to content

CEP-0020: Realtime Enforcement Regions

Draft

Draft proposal for checked realtime, no-allocation, or kernel-suitability regions. V1 has realtime policy guidance and explicit allocation visibility, but no dedicated realtime effect system.

Summary

Catalyst should eventually decide whether source can mark regions or declarations as realtime/no-allocation/kernel-suitable and have the compiler reject forbidden operations.

V1 avoids a second effect system. It relies on explicit capability parameters, visible allocator authority, explicit dispatch, explicit ownership, and lints.

Example

Possible future shape:

@realtime
fn process(input: []const f32, output: []mut f32) {
  const temp = std.collections.Vec(f32).create()
  output[0] = input[0]
}

In a checked realtime region, the allocation above would be rejected or diagnosed according to the accepted enforcement model.

Motivation

Realtime audio and performance-sensitive code need answers to questions such as:

  • can this call allocate?
  • can this region block or perform IO?
  • does this call use hidden dynamic dispatch?
  • does this generated IR carry the required restrictions?

A checked region model could turn those questions into hard diagnostics for code that opts in.

Proposed Direction

The proposal should cover:

  • dedicated attributes such as @realtime, @noalloc, or @kernel;
  • whether annotations apply to functions, blocks, modules, impls, or build profiles;
  • which operations are forbidden;
  • whether violations are hard errors, lints, or profile-specific diagnostics;
  • interaction with allocator APIs, dynamic dispatch, cleanup, resource disposal, and foreign calls;
  • reflection or IR metadata that lets tooling answer allocation/blocking/IO questions.

V1 Compatibility

V1 has no dedicated realtime attributes and no checked realtime region syntax. Active docs should point here for future enforcement instead of treating these attributes as current semantics.