Trait built-in naming convention

[Ken Matsui]

On Thu, May 2, 2024 at 12:18 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 2 May 2024 at 18:38, Ville Voutilainen
> <ville.voutilainen@gmail.com> 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.
>
> The main advantage is that it avoids clashes with std::lib components
> that previously used the __is_foo name and which need to be renamed to
> support a built-in of that name.

I updated the parser to ignore the use of the same identifiers in
existing codes, such as struct __is_pointer in bits/cpp_type_traits.h.
It is working correctly so far, but for example, if there's a
constructor, there would be clashes.

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=df3559d951ba6572e254a1bd1ef9a34b6e543325