From 0bb936a7858e36b8da2eca0eef98161336cca547 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Daniel=20Kr=C3=BCgler?= Date: Sun, 22 Sep 2024 11:28:13 +0200 Subject: [PATCH] New issue from Jiang An: "Uses-allocator construction mechanisms should be opted out for node handles" --- xml/issue4159.xml | 62 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 xml/issue4159.xml diff --git a/xml/issue4159.xml b/xml/issue4159.xml new file mode 100644 index 0000000000..1ed74a5a9b --- /dev/null +++ b/xml/issue4159.xml @@ -0,0 +1,62 @@ + + + + +Uses-allocator construction mechanisms should be opted out for node handles +
+Jiang An +21 Sep 2024 +99 + + +

+Currently, node handle types () have the member +allocator_type type alias, which makes std::uses_allocator report +true for them. However, they don't have allocator-extended constructors, +and it's unclear to me whether it's better to make them have such constructors. +

+The status quo renders the following seemingly reasonable program ill-formed. +

+
+#include <set>
+#include <map>
+
+int main() {
+  std::pmr::set<int> s{1};
+  std::pmr::map<int, decltype(s)::node_type> m;
+  m.emplace(1, s.extract(1));
+}
+
+

+Perhaps we should consistently treat node handles not uses-allocator-constructible. +

+ + + +

+This wording is relative to . +

+ +
    +

  1. Modify as indicated:

    + +
    +

    +[…] +

    +-4- If a user-defined specialization of pair exists for pair<const Key, T> +or pair<Key, T>, where Key is the container's key_type and +T is the container's mapped_type, the behavior of operations involving node handles +is undefined. +

    +-?- For each node handle type NH and any type A, if +uses_allocator<NH, A> is not a program-defined specialization, it meets the +Cpp17BinaryTypeTrait requirements () and its base characteristic +is false_type. +

    +
    +
    2. +
+ + +