From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by sourceware.org (Postfix) with ESMTPS id B25F5385694F for ; Tue, 12 Jul 2022 18:41:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B25F5385694F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f47.google.com with SMTP id h14-20020a1ccc0e000000b0039eff745c53so5338158wmb.5 for ; Tue, 12 Jul 2022 11:41:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=f6vFlyw3gqI0JJ1xyaah7xVXbRrr4K3mjemFZG7TqgU=; b=ZF6Hapg7Q6iXJ4ADPyAdjsWnCClsN7pR6u68jCnWl3Cj7xfAhULn8a58okWbiIckFG q+vlEQfaiGTTU1+ozSwOtMjR/nFKg07K8TSjU24RqSJXBLEJO77j4UOeJSQIkKB3F5kC ERCHwKp+OPe9xoZspETXsHrzUo9nG/pBW4ARZDJ6yqpeXtgjWNyZlnVJEZv0LT88XaL1 kEnOTlo2/vJHkSYUGz/zvK1OTOPIeburBvjmxhP3mvjX5Hrsb64aCO3T+2muquJN5rqw dFMCPUSsHqFbqddixnxw/lvWOztl3U7mmbogNMel107DXjNnW3V8M6ejlHIWGe+qjD62 IAdQ== X-Gm-Message-State: AJIora/md2X+iQ3JZ75HEKrA5uZv4Ds1UkNVfNc3XMpfGzZzzkYAwGbW sonw5n/ASxQDiaMfX4XG/zphAI3HNPo= X-Google-Smtp-Source: AGRyM1tEZzz14f0uzDHU9+YUDm5DpIXnCmsJGrSVAp0RQWYxAdPFyiC6yif/1PXDgiNqJCsLHtnmRQ== X-Received: by 2002:a05:600c:3b23:b0:3a1:90d3:79ae with SMTP id m35-20020a05600c3b2300b003a190d379aemr5369519wms.69.1657651276722; Tue, 12 Jul 2022 11:41:16 -0700 (PDT) Received: from ?IPv6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id r3-20020adfe683000000b0021b81855c1csm10665817wrm.27.2022.07.12.11.41.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 11:41:15 -0700 (PDT) Subject: Re: [PATCH 1/2] Add gcc/make-unique.h From: Pedro Alves To: Jonathan Wakely Cc: David Malcolm , gcc-patches 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> Message-ID: <56684bbd-b056-ecd6-f01b-924b838ec3fe@palves.net> Date: Tue, 12 Jul 2022 19:41:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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:41:21 -0000 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.'