On Tue, Dec 20, 2022 at 4:46 AM Jason C via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Tue, Dec 20, 2022 at 2:07 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> On Tue, Dec 20, 2022 at 7:00 AM connor horman via Std-Proposals
>> <std-proposals_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Be seeing you,
Tony