On Thu, May 2, 2024 at 12:18 PM Jonathan Wakely <jwakely....@gmail.com> wrote: > > On Thu, 2 May 2024 at 18:38, Ville Voutilainen > <ville.voutilai...@gmail.com> wrote: > > > > On Thu, 2 May 2024 at 20:25, Ken Matsui <kmat...@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
