From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: from us-smtp-delivery-124.mimecast.com
(us-smtp-delivery-124.mimecast.com [170.10.133.124])
by sourceware.org (Postfix) with ESMTP id 218273AA982D
for ; Wed, 28 Apr 2021 17:00:49 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 218273AA982D
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
[209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
us-mta-396-PbeHTVaQP7GPQYwHbGphxA-1; Wed, 28 Apr 2021 13:00:46 -0400
X-MC-Unique: PbeHTVaQP7GPQYwHbGphxA-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
[10.5.11.22])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AF0C58042A6;
Wed, 28 Apr 2021 17:00:45 +0000 (UTC)
Received: from localhost (unknown [10.33.36.164])
by smtp.corp.redhat.com (Postfix) with ESMTP id 5D61510016FC;
Wed, 28 Apr 2021 17:00:45 +0000 (UTC)
Date: Wed, 28 Apr 2021 18:00:44 +0100
From: Jonathan Wakely
To: Ville Voutilainen
Cc: libstdc++ , gcc-patches@gcc.gnu.org
Subject: Re: [RFC] Deprecate non-standard constructors in std::pair
Message-ID: <20210428170044.GU3008@redhat.com>
References: <20210407123050.GY3008@redhat.com>
<20210407124654.GZ3008@redhat.com>
<20210407165922.GA3008@redhat.com>
<20210428165735.GS3008@redhat.com>
MIME-Version: 1.0
In-Reply-To: <20210428165735.GS3008@redhat.com>
X-Clacks-Overhead: GNU Terry Pratchett
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/mixed; boundary="vrIGRKnBmQs2THAk"
Content-Disposition: inline
X-Spam-Status: No, score=-14.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT,
RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,
SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
server2.sourceware.org
X-BeenThere: libstdc++@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libstdc++ mailing list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 28 Apr 2021 17:00:50 -0000
--vrIGRKnBmQs2THAk
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
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++
>>>> 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 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.
--vrIGRKnBmQs2THAk
Content-Type: text/x-patch; charset=us-ascii
Content-Disposition: attachment; filename="patch.txt"
commit 24151c175c08222c268d9c37cc8fa255e2b2384c
Author: Jonathan Wakely
Date: Wed Apr 28 17:59:50 2021 +0100
Document deprecation of non-standard std::pair constructors for GCC 12
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index e0ac986e..912fc59b 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -30,6 +30,13 @@ a work-in-progress.
Caveats
+ -
+ Two non-standard std::pair constructors have been deprecated.
+ These allowed the use of an rvalue and a literal 0 to construct
+ a pair containing a move-only type and a pointer. The nullptr
+ keyword should be used to initialize the pointer member instead of a
+ literal 0, as this is portable to other C++ implementations.
+
- ...
--vrIGRKnBmQs2THAk--