How could that work in practice?

The size of those objects would not be fixed? As only sometimes - depending on the analysis - a reference counter is attached.

Is it for stack (automatic/local/scoped) variables? Or also for member variables or base classes?

Is it for safety within a thread or even safety between different threads?

Does the code need special annotations or classes/templates at all? If the analysis proves that e.g. std::shared_ptr is never needed for a variable, it can be optimized away under the as-if rule. Would a better optimizer that can do that be enough?

-----Ursprüngliche Nachricht-----
Von: vxadminMx via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Fr 04.09.2026 06:59
Betreff: [std-proposals] Proposal Idea: Fallback Deterministic Reference Counting for Unprovable Lifetime Profiles
An: std-proposals@lists.isocpp.org;
CC: vxadminMx <vxadminMx@proton.me>;

Hi everyone,

 

I want to gather early feedback on an opt-in language mechanism that introduces a hybrid safety net within the upcoming C++ Safety Profiles framework.

Currently, static lifetime analysis models force a strict binary constraint: code must either mathematically prove safety at compile time or fail compilation completely. This breaks interface ergonomics and blocks easy legacy C++ migration paths.

I am drafting a proposal for a dynamic safety degradation mechanism. Within a translation unit or scope marked with a profile attribute (e.g., [[carries_profile(safety)]]), if local variables or control flow paths cannot be statically verified clean by a borrow checker, the implementation transparently injects deterministic, RAII-based atomic reference counting control blocks at the failure site rather than throwing a hard compilation error.

This ensures complete memory safety at runtime for complex topologies or legacy code paths without forcing the developer to invasively change API layouts to use explicit smart pointer wrappers (std::shared_ptr).

Key areas I'm trying to address in the draft include:

1. Keeping type layouts untouched to avoid ODR/ABI breaks across translation units (using implicit outer pointer indirection only where static proofs fail).
2. Intercepting potential reference cycles during escape-path analysis.
3. Managing cascade deallocation latency by optionally deferring cleanup tasks via execution profiles.

I am finalizing a formal draft plugin via a custom Clang pass to prototype this natively. Before requesting an official P-number document tracker, I would love to hear thoughts on this approach, existing overlaps, or immediate edge cases the evolution groups might object to.

 

-mxreal64

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals