Re: Trait built-in naming convention

[Ken Matsui <kmatsui@cs.washington.edu>]

On Thu, May 2, 2024 at 12:49 PM Jason Merrill <jason@redhat.com> wrote:
>
> On 5/2/24 15:36, Iain Sandoe wrote:
> >
> >
> >> On 2 May 2024, at 20:30, Ken Matsui <kmatsui@cs.washington.edu> wrote:
> >>
> >> On Thu, May 2, 2024 at 10:54 AM Marek Polacek <polacek@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 <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.
> >>>
> >>> 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
> >
>