On Thu, Feb 16, 2023 at 6:08 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Thu, Feb 16, 2023 at 10:31 PM Thiago Macieira wrote:
> >
> > > `foo` is now *moveable*, whereas before (since it stored a `mutex`),
> > > it was not moveable. If I use a `shared_ptr`, it could be copyable
> > > too.
> >
> > Bonus: it allows controlling reentrancy on a set of objects of this class
> > larger than 1 and less than the universe.
>
>
> If you want to retain movability, the syntax is:
>
> void Func(void) noreentry&&;

Ignoring for the moment the... quality of this syntax, how do you
intend to implement that? If there's a dynamic allocation, how do I
hook into it so that I can provide my own memory allocator?

Also, I think you're really missing the point. The quality issue with
your syntax is there because you're trying to do something with the
language that's more complicated than the language should handle.
`virtual` functions work because there's basically one good way to
implement it on any given platform and there's little (good) reason
for a user to want to change things. In theory, we could allow classes
to dynamically select from multiple `virtual` functions, implemented
by giving each class instance its own vtable and dynamically using
them as needed.

But we don't allow that because there's little need to do it, and if
you need it, it's easy enough to implement it manually with a function
pointer in the class.

By contrast, a moveable, or shared_ptr copyable, reentrancy guard is
something that's very reasonable. And if your language feature
*doesn't* cover it, then that would suggest it's perfectly fine as a
library feature in its entirety. But since the only way to cover this
case (and I argue doesn't cover it well) involves bizarre, novel
syntax... that itself is evidence that it probably should be a library
feature.