[libcxx-commits] [libcxx] [libc++] Avoid constructing additional objects when using map::at (PR #157866)

Louis Dionne via libcxx-commits libcxx-commits at lists.llvm.org
Mon Sep 15 08:27:21 PDT 2025


================
@@ -0,0 +1,25 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___TYPE_TRAITS_IS_TRANSPARENTLY_COMPARABLE_H
+#define _LIBCPP___TYPE_TRAITS_IS_TRANSPARENTLY_COMPARABLE_H
+
+#include <__config>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+template <class _Key, class _Arg>
+inline const bool __is_transparently_comparable_v = __is_same(_Key, _Arg);
----------------
ldionne wrote:

This needs documentation. What does it mean to "be transparent"?

Also, shouldn't this include a `is_comparable` check of some sort? Otherwise `__is_transparently_comparable_v<void, void>` it true, but it makes little sense.

Also, how do we handle types whose equality comparison uses e.g. identity of `this` pointer? In that case making a copy of the object might change the result, so pedantically a type could be non-transparently-comparable even if `__is_same(Key, Arg)` is true. I know these types don't work with `map`, but there's nothing specific to `map` in this type trait. I think the minimum we should do is document that aspect of the trait.

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


More information about the libcxx-commits mailing list