> 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).
0.02GBP only, as always
Iain
>
>>
>>> 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
