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--