Hello,

I would like to request feedback possibility of adding C++ language feature to define/constrain certain types the lifetime of object instances is explicitly controlled by the compiler, i.e. where object creation and destruction occur automatically, without programmer, such as:

- object with automatic storage duration;

- a temporary prvalue object destroyed at the end of the current full-expression.

This would be useful for implementing compile-time checking of types that can (or should) be valid only when their lifetime is strictly bounded by the current context (scope), for example:

- capability/token objects;

- objects used to ensure transaction idempotency;

- any RAII-managed resources that must not outlive the local context;

- types for which it is important to impose a compile-time lifetime restriction with predictable destruction at the end of the current scope, such as `std::scoped_lock`.

The rough idea is to introduce two attributes:
[[scope_lifetime]]
[[scope_owner]]

The intended meaning is that objects of a type marked [[scope_lifetime]] must remain under a short-lived deterministic lifetime root, while [[scope_owner]] identifies owner types for which the relevant property is the lifetime of the owner object itself, rather than the physical storage used for the owned objects.

The goal is not to ban dynamic allocation as an implementation technique, but to require that such objects remain under a short-lived deterministic owner root. This is intended to allow ordinary local RAII containers and wrappers to work naturally, while rejecting globals, static/thread_local roots, and standalone dynamically rooted objects for such types.

I have attached a short discussion draft with examples, a semantic outline, and some explicit open questions.

I would be very interested in feedback on whether this problem seems worth solving, whether the proposed direction is coherent, whether user-defined [[scope_owner]] types should be supported, and whether there is earlier work or prior discussion that I should review first.

Thank you.

Kind regards,
Ryabikov Aleksandr