[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) {
----------------
huixie90 wrote:

it is unclear to me what the meaning of this `unchecked` is. I stiff prefer the old name `__unique` , which matches our convention for all algorithms. `__foo` is the internal function that is shared between `std::foo` and `std::ranges::foo`. 

I think what others concern is not only about `equivalent_relation` concept, it is also about the semantic of this algorithm. Even the c++17 version has a "equivalence relation" precondition. It happens that the implementation is currently invoking the predicate only in one direction. if the implementation of `unique` one day does something different in the future, this could break. 

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