On Tue, Dec 20, 2022 at 4:46 AM Jason C via Std-Proposals <std-proposals@lists.isocpp.org> wrote:


On Tue, Dec 20, 2022 at 2:07 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Tue, Dec 20, 2022 at 7:00 AM connor horman via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:

> TBH, delete p = nullptr; reads too much like delete (p = nullptr);, even if it doesn't parse that way,
> that I wouldn't ever want to use it, or attempt reading code that uses it.

Therefore when you see "delete p = nullptr;", irrespective of whether
you're familiar with operator
precedence, you know that it must be setting the pointer to null after
delete'ing it, because nothing
else makes sense.

a = b = 3 and a = (b = 3) are equivalent.

It would be confusing for all involved if delete a = nullptr and delete (a = nullptr) were not equivalent.


Parentheses change the order of things. That's not new. -a + b is not the same as -(a + b).
If you have a suitable overload of unary minus, then you can show that -a = b is not the same as -(a = b)

Of course most people don't know the precedence of delete, so yes it would be confusing - not because parentheses changed the order, but because the precedence of delete is seldom encountered.


Also C++ requires that B be sequenced before A in the statement (A = B), so it's not really clear how to formally make "delete" on the left side have precedence over assignments on the right side.


That's the easy part.  If delete has higher precedence, then make `delete p` return a reference to p, so you have, in effect,  `(delete p) = nullptr`.

Still not worth doing though.  But it is possible.



As an alternative to std::unique_ptr or std::shared_ptr, you can always wrap these sorts of things in macros or a short utility function as well, if needed.

 

 
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Be seeing you,
Tony