From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 9F3D63858D34; Thu, 2 May 2024 17:38:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9F3D63858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9F3D63858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714671488; cv=none; b=gNTc7JbkEA1TfwMhARPbjid1/NOrCdMNZuT6sgzw7uw5FuuoSa54jc24QPE+D0eoS0lw9+m6CC6HUWpI4nXNy36rIM93CYR/dWxX4HMvsHdgT6KC7JNanv9VwRbu/pifVDneb/9NlxOZYEwS2N5kh8jEvyT8Ib87pchLQwcLwU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714671488; c=relaxed/simple; bh=PfquBq5WhT+Pistfp+gjkswSLv0cugp3JjgjR7HGxoA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=vtwN/sh+x+WtqPWv94wxMe4hmXPWozfUMEKgprtIDN9Suhf7Zz/Zpei9YQ85snQ+H/Fy2x+m1w5JBd6S/57TSi6zvBBpCu+TsVnIyH8k4+Wvu7iP0nOhYSlx1yUh0DrPwao74ruBiAVAP7i1Ub4lZ/bDJVAoPD71DZkeT0hFcJY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5196c755e82so10260530e87.0; Thu, 02 May 2024 10:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714671485; x=1715276285; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zf6lHQ0eT5GIW86+1KQE/EFz/NjzPVp3KTz5warhOVk=; b=EteG2rqNZ2x1mSfLyPrSnh60ncp9qlVGRpiWrXoClOANYvMqA3kHmKaa3Y/+g/zST8 oeLNVqKSHMhhOZdeT0Fwt4thIw+6kdkI7AMzxPKhC57JqsTMZ93kTacpMAxx7nYENDe8 0hiUnUCAoIUJ1LGAY+zXdcGwO9SK66H6MIck4+LIlarqFizsvizr//083rX7py0fzLKl sk7zFvRgqeovTtsOtSJlY0uC5l/YL37ULRPB1jMDkjj6NKCi0k+CU4dRuNULHlqW8xSr a8AYJSb4mdYzqIgASqOM4DoPRG5aviyOnS2AjiB9bH6rInC3nOGAsJ3GC5TCdGEi+8Hv 6QYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714671485; x=1715276285; h=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=zf6lHQ0eT5GIW86+1KQE/EFz/NjzPVp3KTz5warhOVk=; b=VTucz9WCFfTuKkpY5nlmbUTwi2zl+vOQBuTaPFMzGbT60MIddvBipQZjsjUdyoMCZO PUapMxVAco1dXVf68eYSS/ZTEKW+aONozkZNwspBo+/UCJQRWvn0MlOge9+eSDjxLK6n XywHMN08DOuN8jeQ4x//w92tphCkPqYYNkLV58shukYkarh9eq17n+adCjkomB3cS3bc XJE0V6WDDDMAclaiup3bk3XisvwVDiGjPda305CklALyMn2g4E3u/v26r+8u7Q+Q3sDd UmwQy84Eqw6EF0r7MLoyGdeSqL7iAB96wQn2Kg+h7eZGVt+bEMlWMH3m5gslzI2iSVDl AeQA== X-Forwarded-Encrypted: i=1; AJvYcCUAEJt8I5G11vjV0Cm1mAW00ZGdlmDIACThc+/7jbSuToNZtrb5n+FS0TPJFLMgkhO2hloMFpgrYqy69HkwFbDI8O5uiNzr/kN8H/k99OddYPbx7ZatI63/uYpsul/r671laIPodpYgk0LwUAKMz4yA2mkn X-Gm-Message-State: AOJu0Yxns8LTgPiGv6MwUIAgRHs6g5iAC63Ryrk560h3ArrTlDiWOPN0 ZZZ04IWyAtTRF+eMvisOtbMM1lzzexBjaIN2LR26+svRVKVwkqdYmGqJjYlMggUFsFejpLng7HQ eolOk4KifMi72RqAyxcB3tx6Wbmo= X-Google-Smtp-Source: AGHT+IGQTZQUZ3leilowVedVHB8Jd5dY+IueNBmqtNYdiEatDPX8kymoruHfPj1ogEHaekNIqnAK9VWyAGzRe+NKB/M= X-Received: by 2002:a05:6512:32ac:b0:51e:543c:a45d with SMTP id q12-20020a05651232ac00b0051e543ca45dmr404238lfe.20.1714671484863; Thu, 02 May 2024 10:38:04 -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: Ville Voutilainen Date: Thu, 2 May 2024 20:37:53 +0300 Message-ID: Subject: Re: Trait built-in naming convention To: Ken Matsui Cc: Jason Merrill , Patrick Palka , Ken Matsui , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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, 2 May 2024 at 20:25, Ken Matsui 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. 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.