On 5/2/24 12:45, Jason Merrill wrote:
On 5/2/24 12:20, Ken Matsui wrote:
On Thu, May 2, 2024 at 8:34 AM Ken Matsui <kmat...@cs.washington.edu>
wrote:
On Thu, May 2, 2024 at 8:16 AM Patrick Palka <ppa...@redhat.com> wrote:
On Tue, 30 Apr 2024, Jason Merrill wrote:
On 2/28/24 11:26, Ken Matsui wrote:
This patch implements built-in trait for std::rank.
__rank seems too short, maybe __array_rank?
Actually, it occurs to me that perhaps we should have been adding
__builtin to
all of these rather than just __ and the library trait name. I
guess it's too
late to do that for the GCC 14 traits, but we could do it for this
group?
Clang already implements many of these built-in, without using
"__builtin" in their name. Shouldn't we be consistent with Clang where
we can?
Since I had already replaced the prefix locally with __builtin, I
submitted patches addressing all other Jason's reviews with that.
Please let me know if we want to use __ and __array_rank.
If Clang already has a corresponding built-in (as with __array_rank,
apparently), let's use the same name; otherwise let's add __builtin to
the new ones.
Eh, this could probably use more discussion.
The practice of omitting __builtin from type-trait builtins goes back to
Paolo's r123366 (cb68ec50) for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
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.
Jason
