From 0fbb14395daff3a57174da9be77bcffef52ad27e Mon Sep 17 00:00:00 2001 From: Jonathan Wakely Date: Wed, 2 Oct 2024 13:02:45 +0100 Subject: [PATCH] Set 3216 to Tentatively Ready --- xml/issue3210.xml | 66 ++++++++++++++++++++++++----------------------- xml/issue3216.xml | 8 +++++- 2 files changed, 41 insertions(+), 33 deletions(-) diff --git a/xml/issue3210.xml b/xml/issue3210.xml index 8a4cb0c62c..2a319d42fa 100644 --- a/xml/issue3210.xml +++ b/xml/issue3210.xml @@ -2,7 +2,7 @@ -<tt>allocate_shared</tt> is inconsistent about removing <tt>const</tt> from the pointer +<title><tt>allocate_shared</tt> is inconsistent about removing <tt>const</tt> from the pointer passed to allocator <tt>construct</tt> and <tt>destroy</tt>
Billy O'Neal III @@ -11,34 +11,34 @@ passed to allocator construct and destroy

-I implemented the fix for LWG and Stephan pointed out there's an inconsistency here +I implemented the fix for LWG and Stephan pointed out there's an inconsistency here for allocate_shared<const T>.

- p3 says that the allocator construct call is done without removing -cv qualifiers, but p7.12 says that the destroy + p3 says that the allocator construct call is done without removing +cv qualifiers, but p7.12 says that the destroy call is done with removed cv qualifiers.

-The fallback for allocator_traits::construct rejects const T* (since it static_casts -to void*), so the most likely outcome of attempting to do this today is to fail to compile, which +The fallback for allocator_traits::construct rejects const T* (since it static_casts +to void*), so the most likely outcome of attempting to do this today is to fail to compile, which is a break with C++17.

Our options are:

    -

  1. Fix the allocator model to deal with const elements somehow, which breaks compatibility -with existing allocators unprepared for const elements here. We would need to extend the allocator +

  2. Fix the allocator model to deal with const elements somehow, which breaks compatibility +with existing allocators unprepared for const elements here. We would need to extend the allocator requirements to allow const T* to be passed here, and fix our default to const_cast.

    3. -

  3. Fix allocate_shared to remove const before calling construct, which -changes the experience for C++17 customers because allocate_shared constructs a T -instead of a const T, but not in a way substantially different to edits +

  4. Fix allocate_shared to remove const before calling construct, which +changes the experience for C++17 customers because allocate_shared constructs a T +instead of a const T, but not in a way substantially different to edits P0674 already made here.

    5. -

  5. Back out allocate_shared's interaction with this part of the allocator model (reverting +

  6. Back out allocate_shared's interaction with this part of the allocator model (reverting this part of P0674 and reopening LWG ).

    7. -

  7. Go around the problem by prohibiting allocate_shared<const T>, which breaks +

  8. Go around the problem by prohibiting allocate_shared<const T>, which breaks existing C++17 customers.

-Billy O'Neal argues that only (2) preserves the design intent P0674 +Billy O'Neal argues that only (2) preserves the design intent P0674 while maintaining compatibility for most allocators and most C++17 customers.

Peter Dimov argues that (1) isn't likely to break enough to matter. @@ -80,8 +80,8 @@ template<class T, class A, ...>

  1. (7.1) — […]

  2. […]

    3. -

  3. (7.5) — When a (sub)object of a non-array type U is specified to have an initial -value of v, or U(l...), where l... is a list of constructor arguments, +

  4. (7.5) — When a (sub)object of a non-array type U is specified to have an initial +value of v, or U(l...), where l... is a list of constructor arguments, allocate_shared shall initialize this (sub)object via the expression

      @@ -89,9 +89,9 @@ value of v, or U(l...), where l... is a list of const

    1. (7.5.2) — allocator_traits<A2>::construct(a2, pv, l...)

    -respectively, where pv points to storage suitable to hold an object of type -remove_cv_t<U> and a2 of type A2 is a -rebound copy of the allocator a passed to allocate_shared such that its value_type +respectively, where pv points to storage suitable to hold an object of type +remove_cv_t<U> and a2 of type A2 is a +rebound copy of the allocator a passed to allocate_shared such that its value_type is remove_cv_t<U>.

    5. @@ -105,11 +105,13 @@ is remove_cv_t<U>. 2024-04-13; Jiang An comments and provides improved wording

    -The currently proposed resolution is meaningless, because "(allocated) storage suitable to hold an object of type -remove_cv_t<U>" is always "storage suitable to hold an object of type U", and vice versa. -Also, the current specification doesn't seem to specify the type of pv in the cases of allocator_shared, +The currently proposed resolution is meaningless, because "(allocated) storage suitable to hold an object of type +remove_cv_t<U>" is always "storage suitable to hold an object of type U", and vice versa. +Also, the current specification doesn't seem to specify the type of pv in the cases of allocator_shared, because pv is merely specified to point some storage instead of an object.

    + +2024-10-02; will be resolved by issue . @@ -148,8 +150,8 @@ template&lt;class T, class A, ...>

    1. (7.1) — […]

    2. […]

      3. -

    3. (7.5) — When a (sub)object of a non-array type U is specified to have an initial -value of v, or U(l...), where l... is a list of constructor arguments, +

    4. (7.5) — When a (sub)object of a non-array type U is specified to have an initial +value of v, or U(l...), where l... is a list of constructor arguments, allocate_shared shall initialize this (sub)object via the expression

        @@ -157,18 +159,18 @@ value of v, or U(l...), where l... is a list of const

      1. (7.5.2) — allocator_traits<A2>::construct(a2, pv, l...)

      -respectively, where pv has type remove_cv_t<U>* and points to storage -suitable to hold an object of type U and a2 of type A2 is a rebound copy of -the allocator a passed to allocate_shared such that its value_type is +respectively, where pv has type remove_cv_t<U>* and points to storage +suitable to hold an object of type U and a2 of type A2 is a rebound copy of +the allocator a passed to allocate_shared such that its value_type is remove_cv_t<U>.

    5. (7.6) — […]

      6. -

    6. (7.7) — When a (sub)object of non-array type U is specified to have a default -initial value, allocate_shared shall initialize this (sub)object via the expression -allocator_traits<A2>::construct(a2, pv), where pv has type remove_cv_t<U>* -and points to storage suitable to hold an object of type U and a2 of type A2 -is a rebound copy of the allocator a passed to allocate_shared such that its value_type +

    7. (7.7) — When a (sub)object of non-array type U is specified to have a default +initial value, allocate_shared shall initialize this (sub)object via the expression +allocator_traits<A2>::construct(a2, pv), where pv has type remove_cv_t<U>* +and points to storage suitable to hold an object of type U and a2 of type A2 +is a rebound copy of the allocator a passed to allocate_shared such that its value_type is remove_cv_t<U>.

      8. diff --git a/xml/issue3216.xml b/xml/issue3216.xml index 33452c9bf5..3c0ba0fcaa 100644 --- a/xml/issue3216.xml +++ b/xml/issue3216.xml @@ -1,7 +1,7 @@ - + Rebinding the allocator before calling <tt>construct</tt>/<tt>destroy</tt> in <tt>allocate_shared</tt>
      Billy O'Neal III @@ -110,6 +110,12 @@ and `pu` is remove_cv_t<U>*. Accepting this proposed resolution would also resolve issue .

      + +2024-10-02; Reflector poll +

      +Set status to Tentatively Ready after six votes in favour during reflector poll. +

      +