[RFC] Deprecate non-standard constructors in std::pair

[Jonathan Wakely]

On 28/04/21 18:00 +0100, Jonathan Wakely wrote:
>On 28/04/21 17:57 +0100, Jonathan Wakely wrote:
>>On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
>>>On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
>>>>On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
>>>>>On Wed, 7 Apr 2021 at 15:31, Jonathan Wakely via Libstdc++
>>>>><libstdc++@gcc.gnu.org> wrote:
>>>>>>I propose that we deprecate the constructors for C++11/14/17/20 in
>>>>>>stage 1, and do not support them at all in C++23 mode once P1951 is
>>>>>>supported. I have a patch which I'll send in stage 1 (it also uses
>>>>>>C++20 concepts to simplify std::pair and fix PR 97930).
>>>>>>
>>>>>>After a period of deprecation we could remove them, and support P1951
>>>>>>for -std=gnu++11/14/17/20 too so that {} continues to work.
>>>>>
>>>>>The proposal sounds good to me.
>>>>
>>>>Thanks. I've created https://gcc.gnu.org/PR99957 so I don't forget.
>>>
>>>Here's a patch to implement it, for stage 1.
>>>
>>>  libstdc++: Deprecate non-standard std::pair constructors [PR 99957]
>>>
>>>  This deprecates the non-standard std::pair constructors that support
>>>  construction from an rvalue and a literal zero used as a null pointer
>>>  constant. We can't just add the deprecated attribute to those
>>>  constructors, because they're currently used by correct code when they
>>>  are a better match than the constructors required by the standard e.g.
>>>
>>>    int i = 0;
>>>    const int j = 0;
>>>    std::pair<int, int> p(i, j); // uses pair(U1&&, const int&)
>>>
>>>  This patch adjusts the parameter types and constraints of those
>>>  constructors so that they only get used for literal zeros, and the
>>>  pair(U1&&, U2&&) constructor gets used otherwise. Once they're only used
>>>  for initializations that should be ill-formed we can add the deprecated
>>>  attribute.
>>>
>>>  The deprecated attribute is used to suggest that the user code uses
>>>  nullptr, which avoids the problem of 0 deducing as int instead of a null
>>>  pointer constant.
>>
>>
>>I've pushed this to trunk, after testing on powerpc64le-linux.
>
>And here's the wwwdocs patch announcing the deprecation.

And the inevitable html validation fix.

Pushed to wwwdocs.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 1250 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20210428/e060bac1/attachment.bin>