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.
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
