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

Jonathan Wakely jwakely@redhat.com
Wed Apr 28 17:00:44 GMT 2021

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.

Pushed to wwwdocs.

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

More information about the Libstdc++ mailing list