Trait built-in naming convention

[Jason Merrill]

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.

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
>