|
| 1 | +<?xml version='1.0' encoding='utf-8' standalone='no'?> |
| 2 | +<!DOCTYPE issue SYSTEM "lwg-issue.dtd"> |
| 3 | + |
| 4 | +<issue num="4313" status="New"> |
| 5 | +<title>Uses-allocator construction of `pair` in `tuple`'s `allocator_arg_t` constructors</title> |
| 6 | +<section> |
| 7 | +<sref ref="[tuple.cnstr]"/> |
| 8 | +</section> |
| 9 | +<submitter>Jiang An</submitter> |
| 10 | +<date>07 Aug 2025</date> |
| 11 | +<priority>99</priority> |
| 12 | + |
| 13 | +<discussion> |
| 14 | +<p> |
| 15 | +<paper num="P0591R4"/> updated the definition of uses-allocator construction to specially handle `pair`. |
| 16 | +Per <sref ref="[tuple.cnstr]"/>/33, it seems that the `allocator_arg_t` constructors should also be |
| 17 | +updated to handle `pair`. However, such a change doesn't seem intended in <paper num="P0591R4"/>, |
| 18 | +and it would significantly complicate tuple. Currently, implementations consistently don't update |
| 19 | +these constructors in C++20. |
| 20 | +<p/> |
| 21 | +Perhaps we should explicitly say that the `allocator_arg_t` constructors don't specially handle `pair`. |
| 22 | +</p> |
| 23 | +</discussion> |
| 24 | + |
| 25 | +<resolution> |
| 26 | +<p> |
| 27 | +This wording is relative to this |
| 28 | +<a href="https://github.com/cplusplus/draft/actions/runs/16749320058/artifacts/3690555293">CD preview draft</a>. |
| 29 | +</p> |
| 30 | + |
| 31 | +<ol> |
| 32 | + |
| 33 | +<li><p>Modify <sref ref="[tuple.cnstr]"/> as indicated:</p> |
| 34 | + |
| 35 | +<blockquote> |
| 36 | +<pre> |
| 37 | +template<class Alloc> |
| 38 | + constexpr explicit(see below ) |
| 39 | + tuple(allocator_arg_t, const Alloc& a); |
| 40 | +[…] |
| 41 | +template<class Alloc, class U1, class U2> |
| 42 | + constexpr explicit(<i>see below</i>) |
| 43 | + tuple(allocator_arg_t, const Alloc& a, pair<U1, U2>&); |
| 44 | +template<class Alloc, class U1, class U2> |
| 45 | + constexpr explicit(<i>see below</i>) |
| 46 | + tuple(allocator_arg_t, const Alloc& a, const pair<U1, U2>&); |
| 47 | +template<class Alloc, class U1, class U2> |
| 48 | + constexpr explicit(<i>see below</i>) |
| 49 | + tuple(allocator_arg_t, const Alloc& a, pair<U1, U2>&&); |
| 50 | +template<class Alloc, class U1, class U2> |
| 51 | + constexpr explicit(<i>see below</i>) |
| 52 | + tuple(allocator_arg_t, const Alloc& a, const pair<U1, U2>&&); |
| 53 | +template<class Alloc, tuple-like UTuple> |
| 54 | + constexpr explicit(<i>see below</i>) |
| 55 | + tuple(allocator_arg_t, const Alloc& a, UTuple&&); |
| 56 | +</pre> |
| 57 | +<blockquote> |
| 58 | +<p> |
| 59 | +-32- <i>Preconditions</i>: `Alloc` meets the <i>Cpp17Allocator</i> requirements |
| 60 | +(<sref ref="[allocator.requirements.general]"/>). |
| 61 | +<p/> |
| 62 | +-33- <i>Effects</i>: Equivalent to the preceding constructors except that each element is constructed |
| 63 | +with uses-allocator construction (<sref ref="[allocator.uses.construction]"/>)<ins>, except that the |
| 64 | +construction behaves as if there were only one `uses_allocator_construction_args` overload and the |
| 65 | +overload behaved the same as the first actual overload without <i>Constraints</i></ins>. |
| 66 | +</p> |
| 67 | +</blockquote> |
| 68 | +</blockquote> |
| 69 | + |
| 70 | +</li> |
| 71 | + |
| 72 | +</ol> |
| 73 | +</resolution> |
| 74 | + |
| 75 | +</issue> |
0 commit comments