I don't think the language should include your idea. It is generally ill
advised/non-standard functionality and is only for covering what iI
consider a design usage flaw with your update/change/notification
mechanism. It does not add any useful functionality that is not already
available through the use of otherwise simple normal coding techniques.

I believe using a technique demonstrated in this Godbolt link does
everything, all the flavors, of all the options, including function
grouping, without any extra overhead, other than what you were already
asking for, without changing the language. Plus by directly including it
in your code, shows intent and it does not hide any functionality.

https://godbolt.org/z/5v1MoMKfz


On Mon, Feb 13, 2023 at 9:09 AM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Mon, Feb 13, 2023 at 5:01 AM Chris Ryan via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > There is a complicating factor here. What if it is a virtual function?
> Are you going to (silently/hidden) block reentrancy for all derived members
> or just in that class?
>
>
> The block only applies to the function which has 'noreentry' written
> beside it. So for example:
>
> struct Dog {
> virtual void Bark(void) {}
> };
>
> struct Labrador : Dog {
> void Bark(void) override noreentry {}
> };
>
> struct BlackLabrador : Labrador {
> void Bark(void) override
> {
> this->Labrador::Bark(); // This will be blocked for re-entry
> }
> };
>
> int main(void)
> {
> Dog doggie;
> doggie.Bark(); // This will never be blocked
>
> Labrador labbie;
> labbie.Bark(); // This will be blocked for re-entry
>
> BlackLabrador blackie;
> blackie.Bark(); // This will never be blocked (specifically,
> BlackLabrador::Bark
> // will always be entered without
> blocking, however the invocation
> // of Labrador::Bark from inside
> BlackLabrador::Bark will be blocked)
> }
>
>
> > Calling a virtual function could skip that level of the object
> inheritance tree and call a much further derived class/member that was not
> marked noreenteranct.
> > And then how would you handle it if a further derived function did a
> base chaining call
> > virtual void Derived::Foo() { ...; Base::Foo(); ...; }
> > but virtual void Base::Foo(); was marked noreenteranct
>
>
> See the above code snippet where I invoke "Labrador::Bark" from inside
> "BlackLabrador::Bark".
>
>
> > What about a pointer to member functions to a base/derived class are you
> going to block them too?
>
>
> Yes. If you have a Labrador object and invoke a member function
> pointer to "Bark" on it then it will block. But if you apply this same
> member function pointer to an object of type Dog or BlackLabrador,
> then it won't block.
>
>
> > Your noreenteranct flag would affect the functionality of derived
> classes (without much warning) and change the entire idea of the design &
> architecture.
> > Seems like too big of an ask.
>
>
> If the member function should never have been re-entered in the first
> place then this is a good thing.
>
>
> > Are you going to have one of your hidden implementation flags for every
> function marked as noreenteranct in your class?
>
>
> Yes, one flag for every function that has 'noreentry' written beside
> it -- although you have given me an idea just now.... perhaps two or
> three member functions could be grouped together. So for example let's
> say we group FuncA, FuncB, and FuncC together... well maybe they could
> share a flag so that only one of the three is ever entered at a time.
> Maybe something like:
>
> struct Monkey {
> void FuncA(void) noreentry_this_object_grouped(excludeABC);
> void FuncB(void) noreentry_this_object_grouped(excludeABC);
> void FuncC(void) noreentry_this_object_grouped(excludeABC);
> };
>
> These 3 member functions would share an "atomic_flag" to prevent reentry.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>