From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id F18353850877 for ; Tue, 12 Jul 2022 15:14:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F18353850877 Received: by mail-ej1-x635.google.com with SMTP id ez10so14842228ejc.13 for ; Tue, 12 Jul 2022 08:14:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kH2L4cf7RYVzelFdCA12zT7w3Ppoxo1NnIY+xjLVl7I=; b=inls7pKAVmjD93ATLqU5NrnjsGolow4SMmGP34Tbj+SpnP8jmn17fbxGjiFiPgpN+Y sYYTJn/qRKtmH9uxWSVn39Ufn/XHAbX6u2BmCv8jYU+sXGqPXYCrN4f66hOJH3Fcm6aV LdTbAUyd4OPpNA1BVOUWqpOYwxBnpesH1LUNzfhDU3Lr3LBnZEwUHVYWDX5ixYcZ64hO swVhmvmfRazoKqWMHp7O3xf0A8wweH5B0f7hYmFKvQkdTvx7m+AyqQKKr7LrkU310Qgl FnMOlI5MtycifNM9LyI6AfkYm3Ma0N+X1JuD5R8hxKiyUeZyeLDpDBsfw0ixHb76LtRe QCNw== X-Gm-Message-State: AJIora8bc9SPuNasa+G2q2EXU1xM8KYN0XWkeIT7xiki1z6Zuoe9rETC ZZU82EjiFe5oqXp95NTs0kUYe3JbYy1Etu3gK9Y= X-Google-Smtp-Source: AGRyM1v8raI9PScoiw0wxT95rDAnUeR7CMEqBxouotShF44CpEZ8c6s56yBd0TD8b7Rx5TX/Q+im9bS3Ehlr4EgMLiM= X-Received: by 2002:a17:907:9627:b0:72b:6d22:4334 with SMTP id gb39-20020a170907962700b0072b6d224334mr7127051ejc.506.1657638852850; Tue, 12 Jul 2022 08:14:12 -0700 (PDT) MIME-Version: 1.0 References: <20220712002527.417444-1-dmalcolm@redhat.com> <03b8afc0-b917-e940-4995-9ba5493567c2@palves.net> <7f2ddb2d-da00-6852-339a-86c7d853087f@palves.net> In-Reply-To: <7f2ddb2d-da00-6852-339a-86c7d853087f@palves.net> From: Jonathan Wakely Date: Tue, 12 Jul 2022 16:14:01 +0100 Message-ID: Subject: Re: [PATCH 1/2] Add gcc/make-unique.h To: Pedro Alves Cc: David Malcolm , gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2022 15:14:19 -0000 On Tue, 12 Jul 2022 at 15:06, Pedro Alves wrote: > > On 2022-07-12 2:45 p.m., Jonathan Wakely wrote: > > On Tue, 12 Jul 2022 at 14:24, Pedro Alves wrote: > >> > >> On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote: > >> > >>> I tried adding it to gcc/system.h, but anything that uses it needs to > >>> have std::unique_ptr declared, which meant forcibly including > >>> from gcc/system.h > >> > >> Did you consider making gcc/system.h include gcc/make-unique.h itself > >> if INCLUDE_MEMORY is defined? Something like: > >> > >> #ifdef INCLUDE_MEMORY > >> # include > >> + #include "make-unique.h" > >> #endif > >> > >> This is because std::make_unique is defined in in C++14. This would > >> mean fewer changes once GCC requires C++14 (or later) and this new header is eliminated. > > > > That's a good idea. > > > >>> (in the root namespace, rather than std::, which saves a bit more typing). > >> > >> It's less typing now, but it will be more churn once GCC requires C++14 (or later), at > >> which point you'll naturally want to get rid of the custom make_unique. More churn > >> since make_unique -> std::make_unique may require re-indentation of arguments, etc. > >> For that reason, I would suggest instead to put the function (and any other straight > >> standard library backport) in a 3-letter namespace already, like, gcc::make_unique > >> or gnu::make_unique. That way, when the time comes that GCC requires C++14, > >> the patch to replace gcc::make_unique won't have to worry about reindenting code, > >> it'll just replace gcc -> std. > > > > Or (when the time comes) don't change gcc->std and do: > > > > namespace gcc { > > using std::make_unique; > > } > > It will seem like a pointless indirection then, IMO. > > > > > or just leave it in the global namespace as in your current patch, and > > at a later date add a using-declaration to the global namespace: > > > > using std::make_unique; > > > > That's not very idiomatic, though. Let me turn this into a reverse question: > > If GCC required C++14 today, would you be doing the above, either importing make_unique > to the global namespace, or into namespace gcc? I think it's safe to say that, no, > nobody would be doing that. Erm, I might well do exactly that, for either case. I don't see a problem with 'using std::make_unique;' into the global namespace in GCC code. It's not a library header being included by arbitrary code, it's a single application that isn't going to have conflicts for some other ::make_unique defined in GCC (because the ::make_unique that is being proposed today would be removed once C++14's std::make_unique can be used). > So once GCC requires C++14, why would you want to preserve > once-backported symbols in a namespace other than std, when you no longer have a reason to? > It will just be another unnecessary thing that newcomers at that future time will have > to learn. I also don't see a problem with importing std::make_unique into namespace gcc for local use alongside other things in namespace gcc. I do consider that idiomatic. It says "the make_unique for gcc code is std::make_unique". It means you only need a 'using namespace gcc;' at the top of a source file and you get access to everything in namespace gcc, even if it is something like std::make_unique that was originally defined in a different namespace.