From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by sourceware.org (Postfix) with ESMTPS id 70A4A385694D for ; Tue, 12 Jul 2022 18:36:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 70A4A385694D 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-f52.google.com with SMTP id n185so5222111wmn.4 for ; Tue, 12 Jul 2022 11:36:36 -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:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2wgU/5dXlcOLp2HyKVh9akvzpA2j6Umayd6VMQh6HOE=; b=w2KoOiFQyt89t8EaJCTJkVd1W9hLQxxOoz+qV7WYpAHW38IOwWszuTv0nKOgt6hne4 G4fm36Np8TDiorlxeB7sMqms7gz3qYarEwGArZk5YX1dxHrDrQQ/KBFNjoSm1JjULJ7P 4bnvMlF6Wo47TZ3TlCufqyM244Sjd9br14rQ6xSud3Wd8NrO/DZ+aoWz95ee1W1mBPfg rvpz/7Ik2ljI+5hW0leEU6fbmslwd5itYUoGOmKbzj8QVjizLrmfFcmdBLXRfBA+3tiI p2R0S0MniDuSWQymRDXXOlQfdj8xmnzyT/mXKHgdjEu34sQOL8CzkTEdBwyRPzrju0/H ts8A== X-Gm-Message-State: AJIora8BtWjL3Ob7nW7uo5/OjbFOIcr8s2xy5kvQ7vxqWRZl6PtbmQGJ f+NlMhnjKcBw7a90Uw+lieDaXcpfXB0= X-Google-Smtp-Source: AGRyM1vGTnWngJcb3YUpaMWTa0NbyV6nh0JwSpoQAzfzpGWmDI93MIDi9LYg6f4zhul0frtuNaauIQ== X-Received: by 2002:a05:600c:1c2a:b0:3a2:ed0a:420c with SMTP id j42-20020a05600c1c2a00b003a2ed0a420cmr5453832wms.126.1657650994739; Tue, 12 Jul 2022 11:36:34 -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 y12-20020a5d620c000000b0021d63fe0f03sm8764950wru.12.2022.07.12.11.36.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 11:36:33 -0700 (PDT) Subject: Re: [PATCH 1/2] Add gcc/make-unique.h 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> From: Pedro Alves Message-ID: Date: Tue, 12 Jul 2022 19:36:32 +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:36:38 -0000 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. Cheers, Pedro Alves