The idea to lock objects for single member function calls was given up and is understood as not working in practice, as the lock often has to go over more than one operation.   That is also a reason IIUC that volatile member functions have not worked out as intended and where removed again from the standard.   -----Ursprüngliche Nachricht----- Von:Henry Miller via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 23.02.2025 23:41 Betreff:Re: [std-proposals] A non-owning but self zeroing smart pointer for single ownership An:Henry Miller via Std-Proposals <std-proposals_at_[hidden]>; CC:Henry Miller <hank_at_[hidden]>; On Sun, Feb 23, 2025, at 15:58, JOHN MORRISON via Std-Proposals wrote: > Hi Jason, > The preamble has relevance. You say that C++ has *always* been in > tension between safety and utility. That is true but due to the US > government saying that the safety hasn't been good enough, there is a > new imperative to pull harder on the safety side. I don't see it as a > fangled paradigm. It is overdue. But it is new and I think we are all a > bit unsure of where the balance should now lie. I see ptr_to_unique as > being on the cusp of this because it is possible to write unsafe code > with it in a multithread environment and it might even encourage you > think it it is ok. You shouldn't because it has nothing to do with what > it is for, but you can. I'm not sure how much of an obligation a > feature has to prevent its incorrect use neither before nor now where > the criteria may have shifted. Most of the discussion has been about > exactly that. There have been outright rejections because it simply > isn't threadsafe, helpful suggestion of how to make it threadsafe and a > suggestion that it may not matter.' It occurs to me that we are all thinking of ptr_to_unique in terms of operator-> and operator*, but going forward it is better to think of smart pointers in terms of reflection.  With reflection we can examine the class we are wrapping and directly created public (and protected?) members from the class in question into the smart pointer and wrap them with whatever code before calling the wrapped function in question. (this may require some additions to reflection that the current C++26 paper does not cover, but pointer_to_unique would be a C++29 paper and can be written in terms of what we get then) What this gives us that operator->() doesn't is direct knowledge when the function is done and thus an obvious place to release the lock. There is one downside that needs to be understood: Pointer_to_unique may have some functions that are also in the wrapped class and thus have shadowing issues if pointer_to_unique has any member other than constructor/destructor/copy/move.  Unique_ptr has a number of such that are sometimes useful and we need to figure out how to handle them.  There are options to handle this (I can think of 3 but I'm sure there are more). Beware of deadlocks in any safe version.  If the a weak pointer action recursively triggers the destruction of the original pointer farther down the call stack you are deadlocks as the callback can never complete. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals