On Wed, 11 Feb 2026 at 16:49, mika.koivuranta via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Following proposal is in markdown format:
>
> # Canonical State Enforcement
>
> ## 1. Abstract
> This paper proposes a C++ standard for a compile-time language feature for expressing and enforcing *canon state* in C++. The proposal introduces the `canon`, `noncanon` and `input` specifiers for variables and functions, enabling compile-time catching of class of bugs by splitting the program into two separate states, which C++26 currently cannot express. The feature is purely opt-in, and imposes no runtime overhead.

Well, the concern here is that

1) you introduce new function types
2) then you need to introduce new function pointer (and reference)
types, and conversion rules thereof
3) then you need to introduce rules for overriding virtual functions
that have these state-qualifiers
4) and transparent function wrappers will have to accommodate these

It's questionable whether the canon state is generally useful enough
to make such big-impact changes to the language.

If I were to write such a canon state system, I would just do it with
classes where the canon type is a property of a class, and various
"this thing can call that thing but not that other thing" is then a
property of a class used in the calls made. Which of course does mean
that you have to shoehorn the canon-state operations into a class API
and you can't just make arbitrary function canon-state functions,
but oh well.