[libcxx-commits] [libcxx] [libc++] __key_equiv is sometimes 2x expensive (PR #175087)

[via libcxx-commits]

================
@@ -29,9 +29,10 @@ _LIBCPP_BEGIN_NAMESPACE_STD
 
 // unique
 
+// For this unchecked algorithm, __pred does not need to be an equivalence relation.
 template <class _AlgPolicy, class _Iter, class _Sent, class _BinaryPredicate>
 [[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX20 std::pair<_Iter, _Iter>
-__unique(_Iter __first, _Sent __last, _BinaryPredicate&& __pred) {
+__unchecked_unique(_Iter __first, _Sent __last, _BinaryPredicate&& __pred) {
----------------
halbi2 wrote:

The meaning of this is that this internal helper algorithm does not have the semantic of the `std::unique` algorithm, that checks where the predicate is an equivalence relation and otherwise UB. This algorithm is unchecked, does not require equivalence relation. There it is different to even the c++17 version. This helper algorithm does not have the same semantics as `std::unique` or `ranges::unique`, therefore it should not have the same name, so I have changed its name accordingly.

"if the implementation of `unique` one day does something different in the future, this could break" -- I do not understand your meaning. This unchecked algorithm is libc++'s implementation of unique, is it not? How could it do something different, without breaking libc++?

This helper function could be named `__oneway_unique` -- the predicate is evaluated only `one way` -- or `__unconstrained_unique` -- it has no constraints -- instead of `__unchecked_unique`. I only copied `unchecked` from other places in libc++ where a preconditioned helper is used.

https://github.com/llvm/llvm-project/pull/175087