Hello Bjorn,The paper is a very interesting reading. The concept of pointer provenance is very innovative. However, provenance means tracking, which means state. It would be interesting to see how it will be implemented without blowing the binary size. One concern though, is that if the provenance property is stored in the pointer bit representation, it risks to break some source code, where some bits are used to store tags. I recall somewhere in clang source code, they use the top 4 bits of a 64bits pointer to store some information related to the pointer type.Also, pointer provenance won't fix the double free bug, where the pointer has the same provenance. In my proposal, I focus on low hanging fruits and quick fixes. Examine the following example:struct A{  int* p;  A(): p{ new int }  {}   void wrap(int* ptr) { p = ptr; } void release() { delete p; throw 123; // <- the danger starts here. } ~A() { delete p; }};int main(){ try{ A a; a.release(); } catch (...) { // handle exception } return 0;} In the example above, we have a double free bug despite the correct code.the pointer p is freed in the release() member function, and in the destructor, when exiting the 'try' block.All that is because 'delete' takes the parameter by copy. The idea behind my proposal is to give the delete expression a side effect (a feedback). 'new' and 'delete' expressions are sensitive functions, yet one has a side effect (new returns a pointer), but the other silently does it action without any feedback, which is wrong in my mindset. Changing delete to take the pointer by reference, has the lowest cost vis-a-vis breaking code. Anyway, I'm past this proposal now. If it is difficult to be understood, it will be difficult to be advocated for, thus not worth the effort.Thanks OgSent from my Galaxy
-------- Original message --------From: Bjorn Reese via Std-Proposals <std-proposals_at_[hidden]> Date: 8/27/25 5:28 PM (GMT+01:00) To: organicoman via Std-Proposals <std-proposals_at_[hidden]> Cc: Bjorn Reese <breese_at_[hidden]> Subject: Re: [std-proposals] Delete...why not a parameter by reference?! This sounds related to pointer provenance. You may want to look intoongoing standardization work on this topic. A good overview is given in: https://people.kernel.org/paulmck/what-on-earth-does-lifetime-end-pointer-zap-have-to-do-with-rcu-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals