P2363R1 Extending associative containers with the remaining heterogeneous overloads (Konstantin Boyarinov, Sergey Vinogradov, Ruslan Arutyunyan)

This was reviewed in ML at 2021-09-27, summarizing the main topics:

Summary

Comment: A concern about turning ill-formed code into runtime exception:

std::set<std::shared_ptr<int>, std::owner_less<>> s;
std::weak_ptr<int> w = /* ... */;
s.insert(w);

This is currently ill-formed because weak_ptr's conversion to shared_ptr is explicit.
The user can choose to ask exception if the weak_ptr is expired by an explicit conversion, or they can choose to get an empty shared_ptr by using w.lock().
With this change the code would become well-formed, but throw bad_weak_ptr at runtime if the weak_ptr is expired
(...) I'm not (yet) taking a position beyond that the problem should be acknowledged and analyzed in the paper.
is distinguishing between explicit meaning "morally the same thing, but conversion is expensive" and "totally different thing" is tricky, and the  example I gave with shared_ptr and weak_ptr is also in the gray area between the two. It may well be a price we have to pay if we want string/string_view to work (and that's like the use case for this, so it had better work). 
       
Authors: (Editor's summary):
I believe this is a relatively rare use-case. I don’t expect that the types that are allowed to be converted explicitly would be also comparable. (...) The solution is to have explicit ctor, this will affect the performance in common use cases.
(...) with having the constraint for explicitness we would force the user to write explicit conversion (to be able to call the overload with key_type) and kill the performance for the described use-case.
We have the implementation based on LLVM libc++ and we already can observe some performance degradation. (...) I believe the mentioned use-case can be considered common enough. And I don’t think that forcing the user to write
something like string_view_variable.data() to be passed to heterogeneous overload is friendly. Please share your perspective.

Comment: Currently, for heterogeneous lookup, the unique-key associative containers do not require that there is at most one match (https://lists.isocpp.org/lib-ext/2019/05/11645.php)
I think the paper should discuss what happens in such cases, particularly for insert_or_assign, operator[], and at (and what try_emplace returns on failure)

     struct HalfIs { int pt; };
     struct Cmp {
     bool operator()(int x, int y) const noexcept { return x < y; }
     bool operator()(int x, HalfIs p) const noexcept { return x / 2 < p.pt;
     }
     bool operator()(HalfIs p, int x) const noexcept { return p.pt < x / 2; }
     using is_transparent = void;
     };

     std::set<int, Cmp> s{ 1, 2, 3, 4, 5, 6 };
     s.find(HalfIs{2});

     In this example, HalfIs{2} compares equivalent to both 4 and 5.
     
Authors: (Editor's summary):
(...) Without the paper applied that code would insert 4 value. With that proposal applied insert would go in heterogeneous lookup and thus, finds 5 and doesn't modify the container. I don't think this use-case is very common, though (I mean that one when you have both homo and heterogeneous comparator). Users should really understand what they are doing. 
And most importantly I am not sure that the current state of the art (without heterogeneous insertion operations) is somthing we want to live with.

Outcome

Please provide a new revision for the paper, which will capture the concerns brought up, and the authors' position.
(few fundamental topics came up. Best to schedule the new revision for LEWG Telecon)

P2363R2 Extending associative containers with the remaining heterogeneous overloads (Konstantin Boyarinov, Sergey Vinogradov, Ruslan Arutyunyan)

A Library Evolution motion was made to advance this paper directly to electronic polling on 2022-01-13. The motion passed with 7 +1s.

2022-01 Library Evolution Electronic Poll Outcomes

Send [P2363R3] (Extending Associative Containers With The Remaining Heterogeneous Overloads) to Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item).

Consensus in favor

Changing target to C++26 -- LWG is out of time for 23.

@joaquintides and I are implementing P2363 for Boost.Unordered and we believe there's a missing constraint in the implementation of transparent unordered_set insert.

Under this proposal as-is, set.insert(set.begin(), set.end()) results in an ambiguity when the Hash and KeyEqual parameters contain their is_transparent member typedefs as the compiler can't decide between insert(const_iterator, K&&) and insert(iterator, iterator).

The wording should be updated to include extra verbiage, similar to try_emplace's constraints:

For the second overload, is_convertible_v<K&&, const_iterator> and is_convertible_v<K&&, iterator>
are both false.

@cmazakas, please don't use this github repo to discuss issues with the design or wording of a paper. This repo is only intended to be used for tracking the status of a paper. Please use the WG21 mailing lists or other public resources or contact the paper authors for further discussion.

P2363R4 Extending associative containers with the remaining heterogeneous overloads (Konstantin Boyarinov, Sergey Vinogradov, Ruslan Arutyunyan)

https://wiki.edg.com/bin/view/Wg21issaquah2023/P2363R5-20230209

poll: include P2363R5 in C++26?

P2363R5 Extending associative containers with the remaining heterogeneous overloads (Konstantin Boyarinov, Sergey Vinogradov, Ruslan Arutyunyan)