From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by sourceware.org (Postfix) with ESMTPS id C7E203857C5B for ; Tue, 12 Jul 2022 14:06:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C7E203857C5B 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-f53.google.com with SMTP id ay25so4796303wmb.1 for ; Tue, 12 Jul 2022 07:06: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:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Xe2miGIpuBgRGBzgLODKTOzUaYRc0jn8IZ366ydFY7Q=; b=BZSEFbPLSnGNMmRm7uQmPR3ZMVpCaantnqg+kNhQ7IsvqQ+1s0fyXNT2wtYijB72hm yxqKI9OIUVuaQFMOhULVm8I6RbWUWKn5EzzBz6ba/kE0+i748Te5tVWGeiIKuCFBpya8 COjw1Cgzwk3dIAULYwA9IaWqj/itI+Lu9azuZlkbrD+Y/fkWAoJJFAnTV4m3pTFuHyNl B2RE0r79c5bm/x5aqZNjJJVP6KDddUXVpmRwzPfUt6VkqnX7C7VEWhGcI5rE7iLB6AA5 I9aEIEZfLtUQFZr6rrG48cWGxohsPYR+m9H2J0Ac/iUaR6YQKykJMnOOwfh5PCJBGfqz uTGw== X-Gm-Message-State: AJIora8pTEP/aKBs/N6QU0kxDbvQuT6PYId+qyfQnj9vLDLdvexmF2Cv wJ8F2oQ2IrH+rzQxucwd2E2sEunqO1U= X-Google-Smtp-Source: AGRyM1tOKvCFJAEfFMZMkJ+5jPZza1EcnR3LMdQo6j4ReNvNc5GGvWwpLZ57spsmtG6vP3fmdmu+gg== X-Received: by 2002:a05:600c:1c1d:b0:3a2:e473:151e with SMTP id j29-20020a05600c1c1d00b003a2e473151emr4285815wms.69.1657634780270; Tue, 12 Jul 2022 07:06:20 -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 n31-20020a05600c501f00b003a2ebb087fbsm2733411wmr.0.2022.07.12.07.06.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 07:06:19 -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> From: Pedro Alves Message-ID: <7f2ddb2d-da00-6852-339a-86c7d853087f@palves.net> Date: Tue, 12 Jul 2022 15:06:18 +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: 7bit 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 14:06:24 -0000 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. 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.