@llvm/pr-subscribers-libcxx

Author: Nikolas Klauser (philnik777)

diff --git a/libcxx/docs/ReleaseNotes/22.rst b/libcxx/docs/ReleaseNotes/22.rst
index a26c5476d421b..6be269cfbbc84 100644
--- a/libcxx/docs/ReleaseNotes/22.rst
+++ b/libcxx/docs/ReleaseNotes/22.rst
@@ -61,6 +61,10 @@ Deprecations and Removals
 Potentially breaking changes
 ----------------------------
 
+- The algorithm for ``multi{map,set}::find`` has been modified, which doesn't guarantee that the first element is
+  returned. If code relies on the first element being returned from ``find`` it may be broken. To fix it use
+  ``lower_bound`` or ``equal_range`` instead.
+
 Announcements About Future Releases
 -----------------------------------
 

Thanks!

As far as I can tell, libstdc++ also returns the first element from find():

https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_tree.h#L3166
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_tree.h#L1936

As does MSVC's STL:

https://github.com/microsoft/STL/blob/main/stl/inc/xtree#L1395

So maybe say something like "libc++ is the first mainstream C++ standard library not returning the first element" to call this out more? I imagine it's going to be fairly ingrained.

For what it's worth, in Chromium all calls of find() I've found so far (so far just 2) wanted the first element. So maybe it might even make sense to change the spec to require this instead of changing implementation behavior 😅 (update: I now also found 2 instances where find() returning any element is fine.)

(…for Chromium, it looks like it'll be feasible to just audit all callers, so I personally don't care all that much. But I imagine people with bigger code bases might have a harder time.)