Re: Trait built-in naming convention

[Ville Voutilainen <ville.voutilainen@gmail.com>]

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.

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.