On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
> 
> 
> On Tue, 12 Jul 2022, 17:40 Pedro Alves, <pe...@palves.net 
> <mailto:pe...@palves.net>> 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

Reply via email to