From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 443C93858408 for ; Thu, 2 May 2024 17:24:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 443C93858408 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.washington.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 443C93858408 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::62d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714670687; cv=none; b=Obyt2YcTQ1XVvepDoCl+96MlaE3DMeKkZMaJcfPLyU0s4BhqWv28JfpBpZ33MNWzyeaaWYqXlbZpng/kczG4mr2I8sfFbJgILYUgXz470ycmhHGWjshYUA3EDrVCJAJvFGGIUsVA/Lsqka1osU73jDD38KdFXwzsbORegqcY9x4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714670687; c=relaxed/simple; bh=RsFvFveHNgS7VAHaNyOWjfglJApquH/UxPAGRyyE39I=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=ipnIYsqGQLqaCfA0v+TVJyoK96vnMFEvS6Gm21PGvxPveVRTTRPy7VqkWC4hN5ok5Qa9LCyjiKqUFQ18yaSpvRUyJ1N7SWMbT0Hj0yzbfEDmNb4fE3ufy82DFcMrYFQ87Uvc3b2HpyjdM62CTgaxYSKUqrNgnOF47JKnXyr2gNg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a596cb8a7dbso193504566b.1 for ; Thu, 02 May 2024 10:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1714670684; x=1715275484; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=G8PcDh4aAS//P5Ecf0Lys/PkxrLf+sN5cKk6hu4+jTI=; b=TYhdSeleTLtqEmKeoqrfsx5rdu6JnYUAB5G0Lcxc7lsNHbJsxFrBqxsFQvVjBCCblW 6rr9B5P++Mt0hrsdIndP7sx4kdclunxdKmbHBm9FdMOBqov90K4L2x/NsL3xw3MQP71o CBXLViVC3vguaLXST8MC3xuZ2eNxGU09ozmLw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714670684; x=1715275484; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G8PcDh4aAS//P5Ecf0Lys/PkxrLf+sN5cKk6hu4+jTI=; b=kpf9aXPtBN1zueTxje7pfogtpVWsB6NffIvST3yJ5FTHqqard770V96XoL9KUG8Azk j38imU0D8HWxMqB26XQI9ja9mzu3ltD5ehCj/zgjVTmhJEPBPP026Ohd+rcK1K+S2vMA qTFHOWn0zGn0WpCos2V+ex38iSvMcS6IKzrRLB98kf8bqtQ96OE/MO4xib3poghdTQcH 96ry7Kqyg6jP5Oh7MbiO2mdH+tKeKUwLkPgD76k8W42x1Z2yNeQ8JVe+mvmoaik9C0Rd t4slhBBwYHDI8eLNF6Fb2urFuuRP++v8SVTiukkgZ2wTdL/SDIXDBiTx1/YQKI/U6CJv Vg6Q== X-Forwarded-Encrypted: i=1; AJvYcCWTfyUf20LnENbBlc4tBVd95P5GB3vHwvgjmDDA1BqH1JoirSdshS4dBxNpKZCVwnriGdek0S9qchy+/1KKJJHFTobwUk0= X-Gm-Message-State: AOJu0YzbBY4Dz5srwXujSKCeFX99TgLVOfqHW9HThVJaHrtqf3w0yeam ArdU080iTPFlco1coKZsD10dPfFDp8i9O0N08Kfmg9rCILSx8t2RUeAMCChmlq77N6vRiSrkDFZ XZIuK8pn0XsFEAkJLGKsaokOu8BWpydN+CYY8 X-Google-Smtp-Source: AGHT+IH6TKe8nmpFP6zJ6huGz7DPxbhU24JeCNhl3wVMO5I2AeJrVKIyvgVcuwd7lWmx8i1HmBXSmD1ekZyDFUmTbvQ= X-Received: by 2002:a17:906:7155:b0:a58:8a33:1a3c with SMTP id z21-20020a170906715500b00a588a331a3cmr113180ejj.72.1714670683831; Thu, 02 May 2024 10:24:43 -0700 (PDT) MIME-Version: 1.0 References: <20240221093616.4001742-1-kmatsui@gcc.gnu.org> <20240228192843.188979-1-kmatsui@gcc.gnu.org> <20240228192843.188979-22-kmatsui@gcc.gnu.org> <8b32b64d-8411-4792-9ffc-b81dbc189e52@redhat.com> <21abf361-86be-4c67-a845-9abc3a88a061@redhat.com> In-Reply-To: From: Ken Matsui Date: Thu, 2 May 2024 10:24:07 -0700 Message-ID: Subject: Re: Trait built-in naming convention To: Jason Merrill Cc: Patrick Palka , Ken Matsui , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, May 2, 2024 at 10:12=E2=80=AFAM Jason Merrill wr= ote: > > 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=E2=80=AFAM Ken Matsui > >> wrote: > >>> > >>> On Thu, May 2, 2024 at 8:16=E2=80=AFAM Patrick Palka 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 wh= ere > >>>> 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=3D26099 > > 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? > Jason >