Re: Trait built-in naming convention

[Ken Matsui <kmatsui@cs.washington.edu>]

On Thu, May 2, 2024 at 10:54 AM Marek Polacek <polacek@redhat.com> wrote:
>
> 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.

So, updating all existing built-in trait names does not seem
realistic.  I think there are two options:

1. As Jason said, we can use the same name as Clang does and otherwise
use __builtin.
2. Or we can simply use __ for all built-in traits to keep consistency
with other built-in traits.

Then, I feel option 2 would sound better since it's consistent across
all built-in type traits and it might confuse Clang when they
implement the same built-in.  Also, it would be easier for me to
implement built-in traits as I don't need to dig into the Clang code
every time I add a new one.

>
> > 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
>