From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 901DD3858D20; Thu, 2 May 2024 19:36:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 901DD3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=googlemail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 901DD3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::330 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714678601; cv=none; b=vOaE9RN/SyOUUNKLlIWsl24NP5fhcQnO/HMK//3FG9MUcybPa7cIQZ9Y1qYGeTCtSRL+f8e0+yMB8dDg2rZ/Ey0wBqtLRFxb20RkfQeOmgdLJ3b2++W4pAgDEYW+YEKpL0+D1MHddKyUqttwoSWojg6Fn8WlkKvPoKchktoxyZ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714678601; c=relaxed/simple; bh=lJ0S5FaDG/aAxq03x2QPa+Ji/5tshPPaIv6ON99ZIrY=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=CPWKgdqpYBQJaBtPOYCd3h5qUeAKj8S1rOWq8o9o/uGVCWr1l6XBKoFSQ8lWCheUCYXmurUse0LP0ulVysNtMzq7DP/BZ9Vl7lK1yELR6jDoTHW3lYfi2kSYBdWZ622pcMB+Wf5n8o/e4+1dzg2AigpUCn0TMEbKyKdEl2Ud65M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-41bab13ca4eso44021855e9.1; Thu, 02 May 2024 12:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1714678598; x=1715283398; darn=gcc.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JKkXdLwzOhHNtuV6bk3Bos+YRz0pgxkxl5VjfnTw42g=; b=W76K6b9etEXN5uOATGOI39IbuHp+QGCw83mY8fmgLkufzFROewYHxvHz56Q6oF6/SR cqJooJ1U0sPT6zCrz16CpHFcbkIb5Ciqcw/25KWpzWOPDu1CaveZJ88nK5YX/TBOxGSh 9WNAkJIbP0+LGq9rnD5suvDSaMDU+IBLYfLHNVwhjQj7tENiI0oOBmU/pYmno7Gla0AA U+0Q4C8SOcZ6Fu7hcEK28UpgD2HUoCq2n0KMAKk049Xk0ATyMwbAbW0Zxmv/kvcGQSiG Tr0QtfMHHgtxtfgWX7Za+wHKr633LDwxzcCe5vQCq87rmY3Iq0soW6FtMIUCm4DtAiWh /Mbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714678598; x=1715283398; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JKkXdLwzOhHNtuV6bk3Bos+YRz0pgxkxl5VjfnTw42g=; b=YjtdzqDIdzFoFoQ41iW6Yf0cdldywFelOVo34VDPo6+Axvs7I3tw7/EOkSakrkXY/3 o/LlaWSUSaQT9wF13VTx4tyspB69LFjHKddHq3AivXISCcHewh88mC8rqdGIwrVX6B5A DLizlWFRG1AIrz1ZY1+Ie3ZB8FrisVeN4mu3TuQDiu8WeNHI/W0GFysBJONlcFz9BlhR mOTNyz/THE2nOmp6zoukMjFXOwVwTvJ8JQoTFsHCwkFxSdD97hYpooLkhui8uGLPvqoG FWjEG7Z6WcU7uents88YVHMSWrpRn6grtT5o835FPpPyY50kktS0MauJoMKoonPtVuCi eXJg== X-Forwarded-Encrypted: i=1; AJvYcCV3TGHqTw2SaeWlepyamcrnUf2tsmVObU/xgKZDSGoEYBuXbe7Fk/Rkhzw+0Y26TZiP1M+sPWAJpHOBWxxvZjOPzDJyBuMSkFupTnefjmf6TASLbUrbuL5ZPPQBmE4hp4oOJhHd2E229IfE/8vAuNhC8pB1 X-Gm-Message-State: AOJu0Yxm675uhdUPlsZsLHo4XSZoTQPnGWZ3hMG1BwY6TTyocSVudG6E NmQOV1yOnOXODOeZC7aXMte1DxZsON3NpHJXSBXy0YcjUq0okpdy X-Google-Smtp-Source: AGHT+IHKyNHidrTYR6Ihi3aJ+KMa/DyR3aKTf58ytiwmnMRDU94MZOaZCQbQ3YVkl9mnjJgLM1up2Q== X-Received: by 2002:a05:600c:4f49:b0:41b:f359:2b53 with SMTP id m9-20020a05600c4f4900b0041bf3592b53mr500971wmq.37.1714678598074; Thu, 02 May 2024 12:36:38 -0700 (PDT) Received: from smtpclient.apple (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id bd23-20020a05600c1f1700b0041bfb176a87sm6736340wmb.27.2024.05.02.12.36.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 May 2024 12:36:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Subject: Re: Trait built-in naming convention From: Iain Sandoe In-Reply-To: Date: Thu, 2 May 2024 20:36:36 +0100 Cc: Marek Polacek , Ville Voutilainen , Jason Merrill , Patrick Palka , Ken Matsui , GCC Patches , libstdc++@gcc.gnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <14D48642-B157-4F2F-B008-F28691274E7A@googlemail.com> References: <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> To: Ken Matsui X-Mailer: Apple Mail (2.3696.120.41.1.8) X-Spam-Status: No, score=-2.5 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 2 May 2024, at 20:30, Ken Matsui wrote: >=20 > On Thu, May 2, 2024 at 10:54=E2=80=AFAM Marek Polacek = wrote: >>=20 >> On Thu, May 02, 2024 at 08:37:53PM +0300, Ville Voutilainen wrote: >>> 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. >>>>>=20 >>>>> Apparently this naming convention follows the MSVC precedent: >>>>> http://msdn2.microsoft.com/en-us/library/ms177194.aspx >>>>>=20 >>>>> 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. >>>>>=20 >>>>> But I don't see any actual reason for this pattern other than that = it's >>>>> what Paolo happened to do in 2007. >>>>>=20 >>>>> I'm not sure what the right way forward is. Perhaps we're stuck = with >>>>> the questionable choices of the past. >>>>>=20 >>>>=20 >>>> 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? >>>>=20 >>>> Until then, I think it would be better to use __ for all built-in >>>> traits. What do you think? >>>=20 >>> 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. >>=20 >> FWIW, I also like __is_constructible better than = __builtin_is_constructible. >=20 > So, updating all existing built-in trait names does not seem > realistic. I think there are two options: >=20 > 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. >=20 > 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 >=20 >>=20 >>> 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 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> Marek