Hi,

What's the motivation for non-static thread-local class members?

What's the motivation for restricting an instance of a class to have
static storage duration?

> If a class without this attribute has a non-static thread_local member variable, a warning should be issued

What would happen if a user tried to instantiate the class outside of
static storage, would that be an error? If so, this should be an error
not a warning. If the user can instantiate a class outside of static
storage, how do you envision that being implemented?

How do you envision a compiler enforcing static lifetimes? How does
this interact with tools like placement new, unions, std::variant,
std::optional, ....?

> This would have been nice to have for a class I'm currently working on.

How so?

Cheers,
Jeremy

On Thu, Oct 2, 2025 at 4:00 PM Walt Karas via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> I suggest allowing non-static thread_local member variables for classes, which would implicitly restrict instances of the class to have static storage duration.
>
> To support this change, I suggest adding the attribute [[static_duration]], for use in class declarations. If a class is declared with this attribute, all of its instances must have static duration. If a class without this attribute has a non-static thread_local member variable, a warning should be issued. (A warning should also be issued if the class has a base class or member variable whose type has implicit or explicit [[static_duration]].)
>
> This would have been nice to have for a class I'm currently working on. The only work-around I could to come up with was to make it a class template where the instantiations are singletons. The template takes a single (class) parameter. The only purpose of the template parameter is to create distinct instantiations, with distinct thread_local member variables.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals