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