From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id CB91C3857C7D for ; Tue, 12 Jul 2022 18:58:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CB91C3857C7D Received: by mail-ej1-x62c.google.com with SMTP id j22so15988790ejs.2 for ; Tue, 12 Jul 2022 11:58:22 -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=Nm4v4Az9Ue+9PT0lejgvbAGn5IIQdPO5tZ4MxCHHdto=; b=xbrsu0emL1sYRJFcMQWG56SRkzPW0igU9VhtO7Oh+PrZgj5VqfXegUkWIC8G0wgjYA dGqbZFMiIyhFnohWNI3ri9QY4hOqa8ktL/Ka87wu5nMt5/7r7DHaq05uwb6ycxJgEEHm UQmUhcA4OnQUy/jtln6mvmsTnlfgPPdmxUZ3SQlHuTUgkH1aE35eBjvn+F4EsYrjQjl2 /ChQhrvztMHLjVF1beGsfHqCYDE16SKDyZ6Gb4FLZpESOucl1pRJ8H/jwwZN7CwVTh4I 7GpGzjF9oRV8FUQoQC3lcM3PyDNBy46AciSZ0noVHOvTFbnAAKNF4/ZS5V+MkuH9f/q5 PytA== X-Gm-Message-State: AJIora/bnL6HNr4CRYL/TPbhvRs1UI00RKe+30kzZYD/Z4v3O23D2PPC 5ABuDdOwhptDzz2tKZWUHV3txUgkCbhJnfLYhr8= X-Google-Smtp-Source: AGRyM1uWQlCIqMQrJMkPeC3ujd5SZgl7WF37Jng9p2gKsVvxOcd1500z0rn27v/ltAPaGALjEdaZgJud3MaSoJSuLeg= X-Received: by 2002:a17:907:9627:b0:72b:6d22:4334 with SMTP id gb39-20020a170907962700b0072b6d224334mr8071460ejc.506.1657652301596; Tue, 12 Jul 2022 11:58:21 -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> <56684bbd-b056-ecd6-f01b-924b838ec3fe@palves.net> In-Reply-To: <56684bbd-b056-ecd6-f01b-924b838ec3fe@palves.net> From: Jonathan Wakely Date: Tue, 12 Jul 2022 19:58:10 +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.9 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 18:58:24 -0000 On Tue, 12 Jul 2022 at 19:41, Pedro Alves wrote: > > On 2022-07-12 7:36 p.m., Pedro Alves wrote: > > On 2022-07-12 7:22 p.m., Jonathan Wakely wrote: > >> > >> > >> On Tue, 12 Jul 2022, 17:40 Pedro Alves, > 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. 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. > > Sorry to reply to myself -- but I'm not sure it is clear what I meant above in the last sentence, so let > me try again: 'the "gnu::unique_ptr" wasn't rewritten as an import of std::unique_ptr into the gnu namespace > just because of history.' [OFFLIST] I considered doing exactly that. But because namespace gnu wasn't used anywhere else in GCC it didn't make sense. If it had been put in namespace gcc, which is still used elsewhere in the GCC codebase, I might have decided differently. But keeping namespace 'gnu' with no content except 'using std::unique_ptr;' would have been pointless. It wouldn't have made it easier for other things in namespace gnu to refer to it, because there were no other things. It wouldn't have allowed 'using namespace gnu;' to make various useful utilities available with a single using-directive, because that would only make one thing available, and 'using std::unique_ptr;' does that just as effectively.