AW: [std-proposals] Float the idea: First-class effect annotations and resource contracts for C++

Hi all,

Following the "Float the idea" step on isocpp.org, I'd like to gauge interest in a direction before writing the formal R0.

Now that C++26 is finalized — shipping both Contracts (P2900) and Reflection (P2996), already in GCC and Clang trunk — the two carriers that Layers 2 and 3 below build on exist for the first time. This direction therefore targets the C++29 timeframe, whose focus on safety makes it a natural fit.

The gap

C++ carries exactly one aspect of a function's dynamic behaviour in its type: noexcept. Beyond that, the things real-time, embedded, and middleware code care most about at an interface boundary — does this function allocate? block? recurse? bounded stack? bounded time on this hardware? — live outside the language: in comments, in MISRA-style prohibitions, or in external WCET tools that re-derive information the programmer already knew but couldn't express, and that can drift from the code.

The direction

I think the right structure is a small, layered program, with each layer independently shippable:

- Layer 1 — Effect sets. Generalize noexcept to a closed, orthogonal family of static effect guarantees: nonallocating, nonblocking, nonrecursing (plus nonthrowing ≡ noexcept). Part of the function type (sound across indirect/virtual calls); inferred where definitions are visible, declared at API boundaries; discharge at well-defined region boundaries (catch-all, arena allocators). Fully static, fully decidable. This is what I would propose first.

- Layer 2 — Quantitative resource contracts. Extend P2900 Contracts with resource predicates (budget(stack).peak <= 4_KiB, budget(heap_bytes).delta == 0, budget(time).peak <= 50us) over an explicit platform/cost model. Three discharge modes — prove (within a decidable fragment), assume + monitor, ignore — mapping onto the four P2900 semantics. The language standardizes the vocabulary and the discharge framework, not a WCET algorithm.

- Layer 3 — Reflective manifest + runtime monitoring. Use P2996 Reflection to read declared envelopes at compile time, emit a cross-module-checkable resource manifest, and inject runtime probes that verify actual execution against the declared envelope. Almost entirely a library on top of P2996/P2900. Useful even with only Layer 1.

Layers 2 and 3 are independent of each other; both depend only on Layer 1 having declared something.

Alternatives considered

The common thread: none of these can publish a composable, interface-level guarantee that callers can check across module boundaries. That is the gap this program fills.

- C++ Profiles. A profile is a set of rules a conforming compiler enforces at compile time (it may inject runtime checks) — not merely "turning constructs off". But a profile is a property of a translation, not part of an interface: it constrains what a piece of code may do (author-facing), whereas an effect/resource envelope publishes what callers may rely on (interface-facing). The two are complementary, not opposed — they share the principle of in-compiler, compile-time enforcement, but point the statement in opposite directions. A library under a bounds profile can become safer internally, yet still cannot tell its clients "I don't allocate on this path, I cost ≤ N µs on this hardware", and clients cannot mechanically check that.
- MISRA C++ / AUTOSAR C++14 / JSF. Constraint regimes: prohibitions, useful in certification, external to the language and non-publishing.
- Purely external WCET / static analysis (aiT, OTAWA, RapiTime). Reconstructs information after the fact, decoupled from the code, so it can drift; nothing checkable at the interface.
- P3271 "function usage types" (Lippincott), a committee-encouraged C++29-timeframe direction. It addresses the same indirect-call concern but keeps the property off the function's own type (it lives on the pointer/reference type) to allow backwards-compatible contractualization. That is a genuinely different tradeoff from Layer 1, which binds the effect to the function type for a published, definition-site, everywhere-visible guarantee. I see them as complementary rather than competing — a usage type could even be expressed over effect-bearing function types — and I'd welcome views on how the two should relate.
- Status quo / noexcept only. noexcept already carries one intensional effect in the type; this works less well as RT/middleware ABI surfaces multiply and need more than the throwing effect.

Prior art

- noexcept (P0012, part of the type since C++17) — the precedent and the Layer 1 blueprint.
- Clang function effects: [[clang::nonblocking]], [[clang::nonallocating]] — an implementation existence proof for Layer 1, used in real-time audio.
- Ada pragma Restrictions, Ravenscar/Jorvik — the gold standard for this in certified RT.
- must_not_suspend (other languages) — precedent for suspension as an effect.

What I'd like feedback on

1. Is SG14/EWG broadly receptive to Layer 1 as a generalization of noexcept — that is, an effect specifier that is part of the function type, not an attribute?
2. Is there interest in attaching resource contracts to P2900's grammar, with the three-mode discharge model — accepting that the language would not compute WCET, only standardize the vocabulary and the discharge framework?
3. Should the manifest + monitoring track be pursued separately via P2996 (SG7 / LEWG), so it doesn't need to wait on Layer 2?

I have draft papers for each layer plus a manifest schema and a worked example, but I'd rather hear the room first.

This comes from several years working on real-time projects across security, automation, and 3D-camera vision. The recurring frustration was the same across all of them: whether the system actually met its real-time target depended on things the interface couldn't express — whether a call allocated, blocked, or stayed within a time budget on the target hardware. The function signatures told us what was computed but almost nothing about the dynamic behaviour that decided whether the result was correct in time. That gap is what this direction is meant to close.

Thanks,

— Michael Galuszka <galuszka.michael@googlemail.com>