I am not claiming that this is a pervasive problem across all C++ code. However, it does arise for types whose meaning must be strictly confined to the current scope.

Such use cases are primarily needed to implement safe memory management and deterministic concurrent programming.

The problem I am trying to address is that the language should be able to guarantee that "this type may exist only in local scope and is guaranteed to be destroyed when the current scope exits"

Without language-level (compiler-enforced) guarantees, it is not possible to implement the use cases described above reliably; at present, they can only be approximated through conventions, code review, or custom tooling.

>
> Понедельник, 6 апреля 2026, 23:12 +03:00 от Andre Kostur <andre_at_[hidden]
> >:
> 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
>
>
>