On Wed, 31 May 2023, 03:22 Sebastian Wittmeier via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I am not sure you understood the point of most of the replies: The level
> of detail for thread synchronization is the wrong one, if you do it on
> container level.
>
>
>
> Compare it to database transactions. Why should the user of a relational
> database deal with them, if you could have every SQL command implicitly
> span a transaction and be done with it?
>
>
>
> Because you want and need to combine a number of commands into one
> transaction. And those are application-specific. Should the flight
> reservation be automatically canceled if the payment fails? Different
> tables are involved, but the C++ standard committee would not know
> beforehand.
>
>
>
> C++ could be extended with ways to simplify creating those middle layers,
> but you cannot spare the programmer from writing the actual application in
> the end.
>
>
>
> Just having a container, where every call is thread-safe by itself, is the
> solution, which is nearly never (without proof of that by statistical data)
> needed. So it probably does not warrant to have classes for it in the
> standard library. Especially to also not give a false sense of security
> that the code would be thread-safe.
>
>
>
> It is simple to generate your own wrapper or access classes or functions,
> if you need that feature.
>

Or use std::experimental::synchronized_value<std::vector<T>>