From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by sourceware.org (Postfix) with ESMTPS id 67AA8385E836 for ; Thu, 2 May 2024 19:30:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 67AA8385E836 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 67AA8385E836 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::e2b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714678261; cv=none; b=PDfJlxT/2ZkMCR6fiGGNYXnpDSu+yHU0mgBwzmRvbD6a9Fby43k84CWZWT5vxs3bfDdUmG7iGxvA3UY1QodlHAPVYWs41Nmxm6oj9GZh/qIq1xgjd4NOgj/VwzZPVO9uPHYZvzBv8p0LJ4JSjQupSuLk/UD/ZhrPGfnlS1j2xxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714678261; c=relaxed/simple; bh=qXhoaKvSbrr9vFRfbME4OnXTyE6eA1dAucDFKSTsZ9o=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=JbZXg/z53IfenfNg5a9jdTqwfK0nchjQP2+TUGvLx7cZdMIV4IPShGGORQFS1bnWjcCfgom+xLZKtal7Sx+KzN3EWHQmbISerh3XfJ6f2cBU3X63LohXbnXaApDbIOBCyAOwAMYg0Sct68MQkuAiuxOKIP95wqZoUNavSBWmYJk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-vs1-xe2b.google.com with SMTP id ada2fe7eead31-47c10a4083fso2457022137.3 for ; Thu, 02 May 2024 12:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1714678258; x=1715283058; 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=zp6pY1Eo4SC2Cxr396B9pA96JwUtoV7hAFka0agJIrA=; b=K/4hr4jFDH1ahP1I5UfbS4BAoZ2R9l88mmlhQBxcAiFKkIQ7eFt+NNiGvSz0r/Xp2d Cxko4AFG1JKfg2jUKCIaAJLn/nofOs0P5vZDJeHYVR3kt+lo3Ppxlf8I4qKFjyB6vXOf kNSAk5dQiCxNPmdpuoPkT5cfAykg8gkN0cfe8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714678258; x=1715283058; 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=zp6pY1Eo4SC2Cxr396B9pA96JwUtoV7hAFka0agJIrA=; b=vc5T+zU0moqmfV7FJYpCuKuxvUS4DQmd4U+LyBgQcEA/L9PEIMS38AG1bwEz6Gd0mi pvh+HV23IyAH2S3ea4O3/wfmRLl3kzYyELFYSHVcJz+go9CmOLMvwPA0Y0WQ35pgH7CU Guj9Ft/6oTWcRqspzsMCcufelGXD3p+fn/d+xUAQwISbivvaHP0MJahfW5BoR1G+NcaX V2FFibkHAthZ9KweWxaEPgbgkU3Y/Yi7A260TeP4D1Lwuydbo6u7uc6dfHLi+NmBq7kL zKtstDuREXmoSCsKKPplf6rCJ6LydLF50wPnm2qBX76P6s5iN29Ojs0FPVVmoC9Qvd9t bvdw== X-Forwarded-Encrypted: i=1; AJvYcCVdgdSQrc6XFeLENrGrzh5ZLsQ55myciOY5GJ75olE1d4Whll2mNg+Z41gygwysMdGI7KZ7NaJOT+o2GlVGc4/NSrMSZJg= X-Gm-Message-State: AOJu0Yyajd/xfjurnCNV3oeXMcIo0HI8C/+AzMo5/+UkabbCah1GhUS8 GmwB5P2iDouznGsrrTOI8r2wQpHWHENB5Hh/+RNMSotKAJijwdvA08yJWzdzvpn8hALLblmvhpr bYZrOetBMVpqIc0+OMWck19wy2eyIjXHh1rqR X-Google-Smtp-Source: AGHT+IH4LTOoxc9jeeGiChr/IfttaSz2S04zmo0ZzPawKsyLWo4ehV+xzQQKElzDDgqR5EV/TxfkJAoS6Xo4R4C8AgY= X-Received: by 2002:a67:f44e:0:b0:47b:9df6:f91f with SMTP id r14-20020a67f44e000000b0047b9df6f91fmr726847vsn.30.1714678258393; Thu, 02 May 2024 12:30:58 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Ken Matsui Date: Thu, 2 May 2024 12:30:22 -0700 Message-ID: Subject: Re: Trait built-in naming convention To: Marek Polacek Cc: Ville Voutilainen , Jason Merrill , 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=-5.0 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:54=E2=80=AFAM Marek Polacek = wrote: > > On Thu, May 02, 2024 at 08:37:53PM +0300, Ville Voutilainen wrote: > > On Thu, 2 May 2024 at 20:25, Ken Matsui wro= te: > > > > There was some discussion of how to name the built-ins back in > > > > https://gcc.gnu.org/pipermail/gcc-patches/2007-March/thread.html#21= 2171 > > > > 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 variou= s > > > > 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 wi= th > > > > the questionable choices of the past. > > > > > > > > > > Hmm, I personally prefer the __builtin prefix. However, it seems tha= t > > > 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_constructib= le. 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. > > > 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 >