Mailing list review, June 15 - July 26 2021

There seems to be a limited interest (4 participants).
Some discussions about wording where we established that the proposed wording correctly forbids comparison between different pointer types.
Because this was not immediately obvious the paper might want to clarify.

Action items:

• Try to provide a stronger motivation
• Consider making the proposed operator hidden friends
• Add a paragraph explaining how the wording works

We do not need to see this again in mailing list review. I think this can be reviewed by LEWG with low priority

P2249R1 Mixed comparisons for smart pointers (Giuseppe D'Angelo)

Sending this back to mailing list review again, hopefully it can go directly from there to electronic ballot.

P2249R2 Mixed comparisons for smart pointers (Giuseppe D'Angelo)

Was seen by LEWG mailing list review, on 10-11.
Attaching a short summary of the discussion (we've looked at R2: https://isocpp.org/files/papers/P2249R2.html)

Summary

1. Issue: Not sure the facility has verbosity benefit over existing code
   For example, this can be done with: auto it = std::ranges::find_if(objects, [=](auto&& o) { return o.get() == input; })

2. Issue: Do we really want sp == x to work everywhere sp.get() == x works, rather than requiring convertibility of x to the type of sp.get()?

3. Issue: Recommendation to use the first instead of the second (or if not, to add rationale to the paper):

   1. (https://godbolt.org/z/P4exEeoqW)

   template<class U>
       requires std::equality_comparable_with<element_type*, U>
          friend bool operator==(const shared_ptr& a, const U& b);

   2. (https://godbolt.org/z/v1Gcv5Eq5) (currently in the paper)

   friend bool operator==(const shared_ptr& a, element_type* b);

   The former works for types that are implicitly constructible from T* and comparable with T*, whereas the latter doesn't. Both forms work for types that are implicitly convertible to T*, which includes array and function types.

4. Issue: consider the following use case:

       template<class T> struct my_ptr: shared_ptr<T> {
            using shared_ptr<T>::shared_ptr;
       };
       
       int main() {
            return std::equality_comparable< my_ptr<int> >;
       }

   Editor's comment: since users should not inherit from shared_ptr, you might want to rephrase the use case (unless this demonstrates something else).

Outcome

Please add the fixes / rationale requested to a new revision. 
It will be best to discuss this paper in the same LEWG telecon as P2404, P2405.

P2249R3 Mixed comparisons for smart pointers (Giuseppe D'Angelo)

P2249R4 Mixed comparisons for smart pointers (Giuseppe D'Angelo)

2022-07-26 Library Evolution Telecon

P2249R4: Mixed comparisons for smart pointers

2022-07-26 Library Evolution Telecon Minutes

Chair: Nevin Liber

Minute Taker: Ben Craig

Champion: Giuseppe D'Angelo

Summary

There were concerns over the unspecified behavior of comparing raw pointers, but those are addressed in the paper by using compare_three_way to perform the operations (although the paper could be clearer on that).

More concerning was ambiguities that could arise if other smart pointers (such as observer_ptr) also adds these comparison operators.

POLL: We should promise more committee time to pursuing P2249, knowing that our time is scarce and this will leave less time for other work.

Outcome: No objection to unanimous consent

Next Steps

Author to return with a paper exploring the ambiguities when mixed comparisons are added to more than one type of smart pointer.

P2249R5 Mixed comparisons for smart pointers (Giuseppe D'Angelo)

P2249R6 Mixed comparisons for smart pointers (Giuseppe D'Angelo)