This looks like a good fix and resolves my concerns about inout_ptr.

As mentioned before, I still have a concern about out_ptr.

If I use a raw pointer:

THING* p;
MakeThing(&p);

I expect p to contain the value returned by MakeThing, even if this returned value was NULL. This expectation applies for both OUT and INOUT.

This expectation is now met for inout_ptr:

unique_ptr<THING> p = make_unique<THING>();
UpdateThing(inout_ptr(p));

If UpdateThing returns NULL, p is now NULL and the value from make_unique has been freed.

This expectation is not met for out_ptr:

unique_ptr<THING> p = make_unique<THING>();
MakeThing(out_ptr(p));

If GetThing returns NULL, p will retain its original value. This is surprising to me. It is inconsistent with the behavior of raw pointers and is inconsistent with the behavior of inout_ptr. It is a fairly subtle issue that might not be noticed right away: if MakeThing fails, we'll be left with a stale thing instead of a new thing.

This is not as clearly a bug as my double-free issue with inout_ptr, but I believe it is incorrect. It would make more sense to me for the old result to be cleared even if the new result is NULL.

Thanks!
Doug

-----Original Message-----
From: JeanHeyd Meneide <phdofthehouse_at_[hidden]>
Sent: Tuesday, November 2, 2021 10:02 AM
To: Doug Cook (WINDOWS) <dcook_at_[hidden]>
Cc: std-discussion_at_[hidden]
Subject: Re: [EXTERNAL] Re: [std-discussion] inout_ptr - inconsistent release()

Dear Doug Cook,

     The version that I believe properly releases the resources and works has been implemented and the fix has been put up in the issue. In a couple of days I'll ping LWG to ask if it's ready to move (or what the procedure is to get it ready to move into the current Working Draft). Once it moves into the Working Draft and all parties are happy, I'll ping the one implementation that already has it implemented for C++23 (MSVC'S STL, I believe) and go from there.

     Again, thanks for letting me know!

Sincerely,
JeanHeyd