Ok, let me illustrate with a silly example:1- let's take the current state of the 'delete expression as par the current pre-conditions, i.e, it doesn’t take by reference, and it doesn't null its argument. Expl:----- begin snippet----{  T* p = new T;   Dll_fn_takes_by_Copy (p);  delete p;}/// somwhere in a dll libraryvoid Dll_fn_takes_by_Copy(T* pt){  T* ptr = new T;  // use ptr, and pt   delete pt;}----- end snippet-----The dll source is inaccessible to me, or my static analyzer. Can you catch the bug?I am pretty sure you did.Instead of deleting 'ptr', the dll deleted 'pt'.Just one character missed unintentionally. How can I guess, what happened in my code?Especially if the dll documentation says explicitly that they don't delete the passed pointer.I fall in double free bug.Now take the same example with the proposal.i.e. the delete expression takes a reference argument, and nulls out it + the guideline pass by reference. ----- begin snippet----{ T* p = new T; Dll_fn_takes_by_ref (p); if(p) delete p;}/// somwhere in a dll libraryvoid Dll_fn_takes_by_ref(T* &pt){ T* ptr = new T; // use ptr, and pt delete pt;}----- end snippet-----Here no matter what unintentional error happens in the dll, I can safe guard against it.Is my example clear?The new code you are proposing is the one that hides a bug. For the first version of the code you said that the DLL function deletes the wrong pointer. In the new version this bug is still there. I prefer to have a double free error at runtime (which is worse than a compile error) instead of a hidden bug.Dear Simon, we are not arguing for argument sake. We are trying to fix problems here.It is not my responsibility to fix library code, but it is my responsibility to protect myself from their bugs.I suggest you start following the C++ core guideline: No owning raw pointers! This would mean that both functions get smart pointers (but the argument to the DLL function is still a raw pointers because it is non-owning). You don’t have to call delete and smart pointers are automatically nullified. A static analyzer can check that raw pointers are always non-owning. This means you are never allowed to call delete on a raw pointer. A static analyzer can check this. The actual bug you are describing for your DLL function would be impossible with a static analyzer that checks the core guidelines (as far as checks can be done).It was already mentioned by Oliver and others, that sometimes people find them selves decaying to raw pointers. What do you suggest to them? -- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals