On Thursday, 16 February 2023 08:16:29 PST Frederick Virchanza Gotham via Std-
Proposals wrote:
> 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?

I'm open to the idea of being convinced, but I am skeptical. Your paper needs
to go to great lengths to explain why we should add a core language that, as
you say:

> 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'

You need to give arguments why this is better than not having it. For example,
C++11 added lambdas, even though we had functors. They were a simpler syntax
for the same thing, but with a lot of advantages. You've said that this could
lessen the risk of introducing bugs, so include that in your paper and
estimate how often people get it wrong.

> When re-entry of a function is prevented, there could be two
> possibilities: (1) Immediately return (i.e. skip the call), or (2)
> Block (i.e. wait until the function has been exited).

Or (3) throw an exception or (4) terminate execution, as in a contract
violation.

> In event-driven
> frameworks, in particular the event-handling systems you have in
> desktop GUI programs, it makes sense to immediately return if an
> attempt is made to re-enter an event handler.

No, it doesn't, at least not in all cases. In particular, good GUI design
usually means not reentering the event loop, which means that your proposed
reentrancy protection wouldn't kick in because the function in question
*isn't* being reentered. The function couldn't use the language syntactic
sugar in the first place and would need to deploy the protection itself.

Additionally, some GUI frameworks have the concept of "GUI thread" meaning
that this activity could only be triggered in one thread, so you wouldn't need
the atomic protection in the first place.

You should investigate other use-cases besides GUI. For example, with
coroutines: what happens if you reenter a suspended/yielded routine? And just
where is the state stored?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering