On Thu, Feb 16, 2023 at 11:16 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Without even going into the technical details . . . . can I just flow
> the question:
> Are people here on the mailing list keen on the idea of being
> able to prevent the re-entry of a function simply by writing something
> like "noreentry" after its name?

Define "keen".

Is it useful to be able to "prevent the re-entry of a function"? Sure.
But that's not what you're asking for; you're asking for a language
feature to do that.

My primary issue is that I am as of yet unconvinced that this
situation comes up often enough to be *deserving* of a language
feature to solve it. Like, even if you ignore all of the
implementation questions (silent modifications to classes, etc), just
on the merits of the idea alone, this does not seem to be worth
changing the language to be able to do.

Language features should have relatively broad impacts. They should
solve problems that lots of users of that language need solving, and
those problems should happen often enough that such a feature should
be relatively widely used. And I just don't see that here. It feels
like a special case issue that crops up on occasion for certain kinds
of programmers.

> It's already possible since C++11 to prevent the re-entry of a
> function, for example by using 'std::mutex' or 'std::atomic_flag', so
> I'm not talking about making something possible that was previously
> impossible.
>
> But if we can prevent the re-entry of a function simply by writing
> something like "noreentry" after its name, then it saves a lot of
> typing and also it lessens the risk of introducing bugs. Furthermore,
> if the prevention scheme is very complicated -- for example if we're
> dealing with a member function and we want to prevent re-entry for the
> same thread and the same object but allow re-entry in all other
> circumstances except when the same thread tries to re-enter for a
> different object, then the locks and locking code can become quite
> complex and susceptible to introducing bugs.

If you can encapsulate this concept into a standard library object
type that a function can be easily written to use (similar to
`once_flag` and `call_once`), then you can achieve the same effect of
reducing or eliminating bugs without changing the *language*.

That's my second issue with this. I don't see any evidence that a
library-based solution would be particularly onerous or error-prone
compared to the language one. Sure, the language solution may be
slightly more convenient and involve fewer apparent names, but is it
really that much of a burden on the user to write?

Is the burden of writing the following sufficient to demand a language feature?:

```
class foo
{
private:
  std::no_rentry nr_;

public:

  int no_reenter() {std::lock_rentry lock(nr_); if(!lock) return -1;
/*do stuff*/}
};
```

So on the one hand, we have something that, while useful, doesn't seem
*deserving* of a language solution. And on the other hand, we have
something for which a library solution appears adequate. It may be
slightly inelegant, but it works.

Plus, the library solution has the advantage of being able to do this:

```
class foo
{
private:
  std::unique_ptr<std::no_rentry> nr_ = std::make_unique<std::no_rentry>();

public:

  int no_reenter() {std::lock_rentry lock(*nr_); if(!lock) return -1;
/*do stuff*/}
};
```

`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.