From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 73323385E836 for ; Thu, 2 May 2024 19:53:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 73323385E836 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 73323385E836 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::636 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714679621; cv=none; b=I5bXCztaC8b/7wAHXiwz2aw+eeRExDud91LvFzCpHJqfEQPkrEjoJ65GdxuR8fsTInD1NGXhG4NNhP6knrT3GUvV1hU2DEKqkYkxWE1d+3bHos/4WcsX+6cTO91jo4fS40jtOyUGGP5xuo4jru3Na66tdQwaORc2z7iLTPzXqtI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714679621; c=relaxed/simple; bh=6Bh53cdzMbJcPUdinyrLwoRiMuKQroe1pCOJXXt/czw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=GRIsHoZW/ll0luhss+8/HeZH0lgPvoM9m0pBp4CZNnxkhXvOM4rJzIrixRO7GL0XB4J/VxSpbiJrIv56XD3Gn4HkIvvdq8Hwk6BIUVhOf75Y8pHWLzIodpCj0SiohdxffbYWrF/G9MAS5bpZDq+oQfHaSK6PKm1mBr3p1Dy/Z/w= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a58fc650f8fso685065066b.1 for ; Thu, 02 May 2024 12:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.washington.edu; s=goo201206; t=1714679617; x=1715284417; 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=kQQ8m4CFBY2O895ReyXe6NWTnCoxmv0M4xfRrUPYvi8=; b=e+bZAKEThMv9ubyez41Ro57544DrW2/VuMP4R9UX4MKEOSiQWMIomfd4SreJVe9eE4 yhxtChxBvrPqr3yzq8z1r6HHNp/466R1zPzGURp7r7xRA26zhfcRGX9JtQwwWULBXduE DitQktH3VdlNHPXv1lDbizrZIWIoctRNPvF/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714679617; x=1715284417; 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=kQQ8m4CFBY2O895ReyXe6NWTnCoxmv0M4xfRrUPYvi8=; b=P2cjHiVTO7q2ZIqhnhIJr9eL21jb466DY8KElkDUkoXoaw2Mjc/CG/3mlChlfBLJqb A2IPtQWp/bYxy4TrgilLbODnHqXeZREFPwf4Hk+0KrC0zFJLmJRHP9nCQaLQepo2ueCX sM74CmWjujtAmdJc3UACD40LKuQ2ZvxtmPvaKC8HB36EFoSKP5kZ3ALOKFPLbGmjc3TD lG0FVvNu+3tr73pFfZ5L0CUEoC0mKOe4jQfZfxuVhQXF759df/+OcBK32Momj6HRrgkJ bTAAvYDUAH3GcHLw0c4hJJHvl3zRGPFaL8ZV58X9D9gik2SpC16sbPhQvizjN8lfYnDy kMxw== X-Forwarded-Encrypted: i=1; AJvYcCWQ29rYbVeg10RIHCs5RGQshxVYRF6rOBNg7QHvwADr2MGWBBIK9D/vWqJc7InYS//k99LffdLZCQkgNd8ax9mDTr3PDFY= X-Gm-Message-State: AOJu0Ywem8MHEbwr2izJqBsceKVaLy+tnRSznDJqvqJlqXIezyRw0mHF MwvrGYhvwmQGFRP6xKVZJ/Rz7s6a85/vRxjnd5TccMAT0CKxzeSnpTlpxiI3ECrgBB6kTVtpqfl hztVqL70Zk4Xm3WFY2Cga9b339doAJStYauuu X-Google-Smtp-Source: AGHT+IEYQjUmreCmVGqA2jz7LUD6xaT/+nLBIocvjff7myd1Z0NptPkGkeTbxSKsBsuKw0nNGFq79y/jrRwyadfqrZM= X-Received: by 2002:a17:907:3f07:b0:a59:8cd2:5b2e with SMTP id hq7-20020a1709073f0700b00a598cd25b2emr15226ejc.38.1714679617062; Thu, 02 May 2024 12:53:37 -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> <14D48642-B157-4F2F-B008-F28691274E7A@googlemail.com> In-Reply-To: From: Ken Matsui Date: Thu, 2 May 2024 12:52:59 -0700 Message-ID: Subject: Re: Trait built-in naming convention To: Jason Merrill Cc: Iain Sandoe , Marek Polacek , Ville Voutilainen , Patrick Palka , Ken Matsui , GCC Patches , libstdc++@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 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 12:49=E2=80=AFPM Jason Merrill wr= ote: > > On 5/2/24 15:36, Iain Sandoe wrote: > > > > > >> On 2 May 2024, at 20:30, Ken Matsui wrote: > >> > >> 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 = 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#2= 12171 > >>>>>> 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 vario= us > >>>>>> 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 w= ith > >>>>>> the questionable choices of the past. > >>>>>> > >>>>> > >>>>> Hmm, I personally prefer the __builtin prefix. However, it seems t= hat > >>>>> we need to reach a consensus across MSVC, Clang, and GCC. Would th= is > >>>>> 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_constru= ctible. > >> > >> 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. > > > > I agree, being consistent with the status-quo is valuable, some decisio= ns > > might have not be the best ones - but I think it would be terribly conf= using > > to mix __ and __builtin (it immediately makes the reader wonder whar th= e > > difference is). > > This seems to be the prevailing sentiment, so let's continue that way. > Thanks for the input. I actually found that we have two built-in type traits prefixed with __builtin: __builtin_is_corresponding_member and __builtin_is_pointer_interconvertible_with_class. Do we want to update these to use __ instead for consistency? > > Jason > > >>>> Most of the existing builtins for traits don't use a __builtin prefi= x. > >>>> 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 n= ame. > >>>> > >>> > >>> Marek > > >