It’s not immediately clear to me that this is a pervasive problem. Do you
have some concrete examples of where this is actually a problem?

Should this be limited to standard library containers? I would suggest
not. Why forbid a user defined container, or boost/qt/etc libraries?

Naming can be bikeshedded later.

On Mon, Apr 6, 2026 at 12:36 PM Рябиков Александр via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>