public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: David Malcolm <dmalcolm@redhat.com>,
	Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 1/2] Add gcc/make-unique.h
Date: Tue, 12 Jul 2022 19:49:51 +0100	[thread overview]
Message-ID: <0cd5abb1-6832-fa46-c0f3-7000dae97849@palves.net> (raw)
In-Reply-To: <a846c8fb557944c897d511357493d06722af0387.camel@redhat.com>

On 2022-07-12 7:36 p.m., David Malcolm wrote:
> On Tue, 2022-07-12 at 17:40 +0100, Pedro Alves wrote:

>>>
>>
>> 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?
> 
> Pedro, it feels to me like you're constructing a strawman here. 
> Neither me nor Jonathan are proposing that.
> 

See my other reply.

I am actually appalled at how the conversion seems to have derailed.

> I just want to be able to comfortably use std::unique_ptr in GCC in the
> places for which it makes sense, and being able to use "make_unique" is
> a part of that.

My suggestion was simple:

wrap your make_unique in namespace gcc, so that later on when we get to
C++14, yanking it out causes as little churn as possible, with just a 3 letters
for 3 letters replacement.  I never thought this would be objectionable.

If you don't want to do that, that's fine, the churn will happen in the future,
but it's no big deal.  You'll get to live with shorter make_unique for a few years
(my bet is not forever).

> 
> Hope this is constructive
> Dave
> 
> 

  reply	other threads:[~2022-07-12 18:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAH6eHdSnGwtScODMveYha1S5WiDo6YsexN_pRqe9n4vq-Pmkig@mail.gmail.com>
2022-07-12  0:25 ` David Malcolm
2022-07-12  0:25   ` [PATCH 2/2] analyzer: use std::unique_ptr for pending_diagnostic/note David Malcolm
2022-07-12  6:48   ` [PATCH 1/2] Add gcc/make-unique.h Jonathan Wakely
2022-07-12  8:13     ` Jonathan Wakely
2022-10-26 20:40     ` [PATCH v3] " David Malcolm
2022-11-02 21:45       ` Jason Merrill
2022-07-12 13:23   ` [PATCH 1/2] " Pedro Alves
2022-07-12 13:45     ` Jonathan Wakely
2022-07-12 14:06       ` Pedro Alves
2022-07-12 15:14         ` Jonathan Wakely
2022-07-12 16:40           ` Pedro Alves
2022-07-12 18:22             ` Jonathan Wakely
2022-07-12 18:36               ` Pedro Alves
2022-07-12 18:41                 ` Pedro Alves
2022-07-12 18:58                   ` Jonathan Wakely
2022-07-12 18:59                     ` Jonathan Wakely
2022-07-12 18:50                 ` Jonathan Wakely
2022-07-12 18:56                   ` Pedro Alves
2022-07-12 18:36             ` David Malcolm
2022-07-12 18:49               ` Pedro Alves [this message]
2022-10-21 16:01 David Malcolm
2022-10-25 23:00 ` David Malcolm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0cd5abb1-6832-fa46-c0f3-7000dae97849@palves.net \
    --to=pedro@palves.net \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely.gcc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).