On Fri, 17 Feb 2023 at 01:28, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Feb 17, 2023 at 2:10 AM Thiago Macieira wrote:
> >
> > auto Func() const && noexcept noreentry && -> S &&;
>
> Edward Catmar poststed:
> >And how do you specify which allocator to use for the stable per instance
> state?
>
>
> I have revised the syntax. You can use normal stack variables for the
> mutexes/flags by doing:
>
> void Func(void) const && noexcept noreentry -> T &&;
>
> But if you want it to be movable, you do:
>
> void Func(void) const && noexcept noreentry<std::allocator> -> T &&;
>
> Of course, you can put any allocator you want in there. The above line
> can also be written in shorthand:
>
> void Func(void) const && noexcept noreentry<new> -> T &&;
>
>
> Edward Catmar posted:
> > Come to think of it, what happens if that function is invoked on a moved
> from object?
>
> Not sure what you mean here. I don't see why this would be more
> complicated than if the function were invoked on an object that hasn't
> been moved.
>

A moved from object doesn't own a lock.

By the way in previous code examples posted by other people, I can
> understand where you've used unique_ptr<atomic_flag> or
> unique_ptr<mutex> in order to make the object movable. I don't however
> understand how you would use shared_ptr here, because then you could
> have two objects in existence but only one lock (because the two
> shared_ptr's refer to the same lock). I don't understand.
>

So they share a lock. Presumably there are use cases for only being able to
use one object at a time, for a set of objects linked in this way.