Trait built-in naming convention

[Marek Polacek]

On Thu, May 02, 2024 at 08:37:53PM +0300, Ville Voutilainen wrote:
> On Thu, 2 May 2024 at 20:25, Ken Matsui <kmatsui@cs.washington.edu> wrote:
> > > There was some discussion of how to name the built-ins back in
> > > https://gcc.gnu.org/pipermail/gcc-patches/2007-March/thread.html#212171
> > > but __builtin wasn't discussed.
> > >
> > > Apparently this naming convention follows the MSVC precedent:
> > > http://msdn2.microsoft.com/en-us/library/ms177194.aspx
> > >
> > > I notice some discussion of this pattern around Clang adding various
> > > built-ins in https://github.com/llvm/llvm-project/issues/61852
> > > indicating that this is a policy based on precedent.
> > >
> > > But I don't see any actual reason for this pattern other than that it's
> > > what Paolo happened to do in 2007.
> > >
> > > I'm not sure what the right way forward is.  Perhaps we're stuck with
> > > the questionable choices of the past.
> > >
> >
> > Hmm, I personally prefer the __builtin prefix.  However, it seems that
> > we need to reach a consensus across MSVC, Clang, and GCC.  Would this
> > be realistically possible?
> >
> > Until then, I think it would be better to use __ for all built-in
> > traits.  What do you think?
> 
> My 0.02: __builtin as a prefix doesn't serve much of a purpose.
> Consider __is_constructible. It doesn't add value
> to make that __builtin_is_constructible. It's a built-in. Of course
> it's a built-in. It's a compiler-implemented trait, and
> this is just the intrinsic that implements it.

FWIW, I also like __is_constructible better than __builtin_is_constructible.
 
> Most of the existing builtins for traits don't use a __builtin prefix.
> Not in GCC, not in other compilers. They are indeed
> just double-underscored versions of the traits. I think that's fine,
> and consistent. There's precedent for this
> across Embarcadero, Clang, MSVC, and GCC. See
> https://clang.llvm.org/docs/LanguageExtensions.html
> 
> Yes, I know it's inconsistent with other built-ins that aren't C++
> library traits. But the water's been flowing under
> the bridge on that question for a while now.
> 
> I would also prefer at least considering mimicking a trait builtin's
> name if some other compiler did it first. That's not a hill
> to die on, we don't need to be 100% compatible including the naming,
> but if we can, we should just use a name that was
> chosen by someone else already. It's just nice to have the same name
> if the traits do exactly the same thing. If they don't,
> then it's good and in fact very good to give our trait a different name.
> 

Marek