Sent from my Galaxy
-------- Original message --------From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Date: 8/24/25 7:35 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Jason McKesson <jmckesson_at_[hidden]> Subject: Re: [std-proposals] Delete...why not a parameter by reference?! On Sun, Aug 24, 2025 at 12:21 PM organicoman via Std-Proposals<std-proposals_at_[hidden]> wrote:>>>>>> Sent from my Galaxy>>> -------- Original message --------> From: David Brown <david.brown_at_[hidden]>> Date: 8/24/25 4:41 PM (GMT+01:00)> To: organicoman <organicoman_at_[hidden]>, std-proposals_at_[hidden]> Subject: Re: [std-proposals] Delete...why not a parameter by reference?!>>>> On 24/08/2025 16:41, organicoman wrote:> >> >> >> That would be nice - if it had the slightest influence on the issue,> >> which it does not.> >> >> If you use "delete p;", and then try to dereference p, then the> >> behaviour is undefined. /Anything/ can happen - including launching> >> nasal daemons, or crashing the program, or deleting your files, or> >> coincidentally doing something useful. It does not matter if "p" is> >> assigned to nullptr, left unchanged, or has a random value - the> >> behaviour is still undefined.> >> > Yes true, but atleast you can check if a delete was called on your> > pointer, then you can do this:> >> > if (m_ptr) // if false then definitely deleted.> >>> Anyone who is able to check their pointers before use, is equally able> to assign 0 to deleted pointers.>> {> T* p = new T;> Dll_fn_takes_by_Copy (p);> delete p;> }>> Show me how.If `Dll_fn_takes_by_Copy` maintains a copy of that pointer, thenthere's an ownership problem. Either the caller is not correctlymanaging the lifetime of `p`, or `Dll_fn_takes_by_Copy` is improperlystoring a pointer that it shouldn't.Also, if `Dll_fn_takes_by_Copy` is actually storing the pointer, theywill not store a *refernce* to a pointer, even if that function takesthe pointer by reference.If you start if'ing, about a function that belongs to library with a closed source, that's a big No No.We want to be free of guess work.We need minimal effort to stay correct.The proposal is about protecting ourselves from unintentional mistakes.I have a pointer and I want to pass it to a function:There are 3 cases:1- the function will own the lifetime2- the function will not modify the pointee3- the function will inspect the pointerFor the first case, pass by copy, and make your pointer variable a temporary i.eDll_fn_takes_by_Copy (new T{})Or{ T* p = new T Dll_fn_takes_by_Copy(p);} // p dead here2nd case pass by const&Dll_fn_takes_by_const_ref(T* const&);You will ensure that the pointer and the pointee are safe from any modifications.3rd case, pass by reference Dll_fn_takes_by_ref(T* &)You will ensure that even if the pointee is modified, there is no accidental delete of the pointer. Why? Because the proposal says that delete expression takes by reference and nulls out the parameter.So from a caller perspective, I give you a pointer and when I return from the callee I find it nullptr, that's a side-effect that your API doesn't respect its contract (either by mistake or intentionally)It's a team work, with this proposal, we help library implementers to catch bugs.> A language change only helps people avoid mistakes if it does so> automatically or with significantly greater convenience than they> already have. Your suggestion only helps people who are careful in> their coding, and those people are already careful and don't make the> mistakes that your change could prevent.>> If you want to help less careful programmers avoid mistakes, campaign> for std::unique_ptr and friends to have validity checking on> dereference, throwing exceptions on null pointers. (The campaign> wouldn't work because people don't want that extra overhead.)>> I understand why everyone is on the defensive, and I agree totally that we should not obstruct the smart pointer campaign.>> But library implemented and low level will definitely use raw pointers....just show me how many std::vector implementation uses smart pointers for its internal data pointer.Well, they're certainly not going to start taking *references* to rawpointers. And your proposal doesn't actually work unless everyonespontaneously does that. If you're going to make everyone update theircode, maybe make them do it to a good answer.They won't change a blip.....observe that the call site won't changedelete(void*) => delete (void* &)At call sitedelete(p) => delete(p);And that's the same for all other functions that take raw pointers....std::deallocate, construct....etcABI wise, Ahhh, yes it will hurt, unless compiler magician find a clever way.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals