From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from longisland.snafu.de (longisland.snafu.de [IPv6:2001:1560:3:255::153]) by sourceware.org (Postfix) with ESMTPS id 744BA3858D33; Tue, 8 Aug 2023 03:03:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 744BA3858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=berlin.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=berlin.de X-Trace: 507c6e696b6f6c61736b6c6175736572406265726c696e2e64657c37332e323331 2e372e3234327c3171544430382d3030303964782d47487c313639313436333739 37 Received: from longisland.snafu.de ([10.153.10.49] helo=localhost) by longisland.snafu.de with esmtpsa (Exim 4.94.2) id 1qTD08-0009dx-GH; Tue, 08 Aug 2023 05:03:18 +0200 Content-Type: multipart/alternative; boundary="------------eZikAlWGNFflSCBJmWANAoNp" Message-ID: <19c14d57-574b-9b31-de5a-a0590e189ce6@berlin.de> Date: Mon, 7 Aug 2023 20:03:05 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: GCC support for extensions from later standards Content-Language: en-US To: Jason Merrill Cc: gcc@gcc.gnu.org, Louis Dionne , Mark de Wever , aaron@aaronballman.com, libstdc++ References: <3A4C9996-750B-4E3F-8F30-E3DA4366C7B5@berlin.de> From: Nikolas Klauser In-Reply-To: X-VISP-ShouldScan: 1 X-VISP-Virus-Check: clean X-VISP-Spam-Score: -0.5 (/) X-VISP-Spam-Report: This message has been scanned on "longisland.snafu.de" to identify if it is considered spam or not. Contact the support hotline for details. Content analysis details: (-0.5 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.5 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [nikolasklauser[at]berlin.de] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 KAM_DMARC_STATUS Test Rule for DKIM or SPF Failure with Strict Alignment X-VISP-Spam-Max-Score: +++++ X-SA-Exim-Connect-IP: 73.231.7.242 X-SA-Exim-Mail-From: nikolasklauser@berlin.de X-SA-Exim-Scanned: No (on longisland.snafu.de); SAEximRunCond expanded to false X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,KAM_DMARC_STATUS,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,TXREP,T_SPF_PERMERROR 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: This is a multi-part message in MIME format. --------------eZikAlWGNFflSCBJmWANAoNp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 06.08.23 12:19, Jason Merrill wrote: > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser > wrote: > > Hi everyone! > > I'm working on libc++ and we are currently discussing using > language extensions from later standards > (https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/4). > By that I mean things like using `if constexpr` with `-std=c++11`. > GCC has quite a lot of these kinds of conforming extensions, but > doesn't document them AFAICT. While discussing using these > extensions, the question came up what GCCs support policy for > these is. Aaron was kind enough to answer these questions for us > on the Clang side. Since I couldn't find anything in the > documentation, I thought I'd ask here. > > So, here are my questions: > > Do you expect that these extensions will ever be removed for some > reason? If yes, what could those reasons be? > > > Potentially, if they don't actually work properly in earlier standard > modes.  I recently noticed that while we allow DMI and =default in > C++03 mode with a pedwarn, combining them doesn't work. > > Some of the extensions are needed by libstdc++ and are therefore well > tested; these are extremely unlikely to ever be removed.  libstdc++ > folks, is there a list of these? > > Would you be interested in documenting them? > > > That would be useful, yes. > > There is a patch in review to add __has_feature/__has_extension to > G++, which would seem like a suitable context for this documentation. > > Aaron noted that we should ask the Clang folks before using them, > so they can evaluated whether the extension makes sense, since > they might not be aware of them, and some might be broken. So I'd > be interested whether you would also like us to ask whether you > want to actually support these extensions. > > > Sounds good. > > Jason Thanks for the answers! There are a few really interesting extensions that I would like to use: - inline variables - variable templates - `if constexpr` - fold expressions - conditional explicit - static operator() (https://godbolt.org/z/5n9Y4h69n) Is anybody aware of any problems with these extensions? I'd be happy to provide a patch to add these extensions to the documentation, but I couldn't figure out how to build the documentation without building all of gcc. Nikolas --------------eZikAlWGNFflSCBJmWANAoNp--