From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id B57D5385AE4E for ; Tue, 12 Jul 2022 18:50:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B57D5385AE4E Received: by mail-ej1-x629.google.com with SMTP id u12so15922959eja.8 for ; Tue, 12 Jul 2022 11:50:26 -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=VpicI4VUj29P4zoauCZkdjmW/InWZqg9dERqgIFx/tc=; b=bB42Ua3ynx9JCU3O1qncJdYJOgwHvomUaTBq6rrSUByC21Xq1G78SXRzsp17xcEKZ8 CotdgyfZT6hQqm/SipDMBbqL73QF5a/tL0A1KUaZmVBqKh7g/t48XP9hcMaadEMfkOKa GNqhWe6k6GPoS8S21f2eScpFli111cytK/XlvZwWO8sEgsBaSwbewsLhaZBCwXCW/Cbe as3dFgzTWf6dVXyU49Nrel3O2WiyTlrzfO4sp2tl+VvGuzrMs61CfzSqHkVFcQCs8mhw pNFcxlcka5dYriuogl9SXctTRMs+enYe9f92PacXg6HALewnqe/g1cRl28d6u84Fs7rm I17A== X-Gm-Message-State: AJIora/ItnBb7vQpLWdxT9ov1f8HU/t4wniSQJD7P4YHGbTramgi+r3Z MO7N/VDatR7JSoS9M8iGBHB1sHiSa4TxlXDTwGA= X-Google-Smtp-Source: AGRyM1thDw2fZry8fI5RvvfqT9apmxFxhhuYzlsRLZTE9lhATdaMB9owdF3ScrjjOhO82M6p7BZPCBxP1a7I8Nnvu2M= X-Received: by 2002:a17:907:60d1:b0:726:a049:7740 with SMTP id hv17-20020a17090760d100b00726a0497740mr25124293ejc.215.1657651825510; Tue, 12 Jul 2022 11:50:25 -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> <55f00de5-6c6b-51f3-01d4-5f7710e2c792@palves.net> In-Reply-To: From: Jonathan Wakely Date: Tue, 12 Jul 2022 19:50:12 +0100 Message-ID: Subject: Re: [PATCH 1/2] Add gcc/make-unique.h To: Pedro Alves Cc: David Malcolm , gcc-patches 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, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 18:50:28 -0000 On Tue, 12 Jul 2022, 19:36 Pedro Alves, wrote: > On 2022-07-12 7:22 p.m., Jonathan Wakely wrote: > > > > > > On Tue, 12 Jul 2022, 17:40 Pedro Alves, pedro@palves.net>> wrote: > > > > On 2022-07-12 4:14 p.m., Jonathan Wakely wrote: > > > > >> 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. > > > > > > > If that's the approach, then GCC should import std::unique_ptr, > std::move, > > std::foo, std::bar into the gcc namespace too, no? Are you really > going > > to propose that? > > > > > > No, I don't follow the logic of "if you do it for one thing you must do > it for everything". That's a straw man. But I don't really mind how this > gets done. Your suggestion is fine. > > > > It isn't a strawman, Jon. Maybe there's some miscommunication. The > conversion started (and part of it is > still quoted above), by thinking about what we'd do once we get to C++14, > and my suggestion to optimize > for that. Yeah, and I don't think optimizing for indentation is the right trade off. Putting something in a namespace with a three-letter name just so you don't have to re-indent some statements in a few years seems odd. I see no technical difficulty replacing a custom make_unique (in any namespace) with std::make_unique at a later date. If a namespace made sense to avoid name clashes, or to enable finding functions by ADL, or other technical reasons, I'd be all for it. But no such rationale was given, and using a namespace for indentation just seems odd to me. But I really don't care. Putting it in the global namespace or a 'gcc' namespace or anything else appropriate to GCC is fine. I'll leave this thread now. I don't think this is very constructive and I'm sorry for objecting to the suggestion. When we get to the point when we require C++14, make_unique is no longer > different from any other > symbol in the std namespace, and there will be no reason to treat it > differently anymore. Like, if someone at > that point proposes to remove the global make_unique or gcc::make_unique, > and replace all references with > std::make_unique, there will be no real ground to object to that, why > wouldn't you want it? This is very > much like when you removed "gnu::unique_ptr" (not going to miss it) a few > months back -- you replaced > it by "std::unique_ptr"; gnu::unique_ptr wasn't kept just because of > history. > > Cheers, > Pedro Alves >