On Thu, May 2, 2024 at 12:49 PM Jason Merrill <ja...@redhat.com> wrote: > > On 5/2/24 15:36, Iain Sandoe wrote: > > > > > >> On 2 May 2024, at 20:30, Ken Matsui <kmat...@cs.washington.edu> wrote: > >> > >> 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. > > > > I agree, being consistent with the status-quo is valuable, some decisions > > might have not be the best ones - but I think it would be terribly confusing > > to mix __ and __builtin (it immediately makes the reader wonder whar the > > difference is). > > This seems to be the prevailing sentiment, so let's continue that way. > Thanks for the input.
I actually found that we have two built-in type traits prefixed with __builtin: __builtin_is_corresponding_member and __builtin_is_pointer_interconvertible_with_class. Do we want to update these to use __ instead for consistency? > > Jason > > >>>> 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 > > >
