GCC support for extensions from later standards

GCC support for extensions from later standards

[Nikolas Klauser]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

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?

Would you be interested in documenting them?

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.

Thanks,
Nikolas

Re: GCC support for extensions from later standards

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de>
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

Re: GCC support for extensions from later standards

[Jonathan Wakely]

On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++
<libstdc++@gcc.gnu.org> wrote:
>
> On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de>
> 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?

We use variadic templates and long long in C++98. We use a DMI in
__gnu_cxx::__mutex even in C++98. I don't think we unconditionally use
anything else, because we can't rely on it being available when using
non-GCC compilers, or when compiling with -Wsystem-headers -pedantic.
We don't use if-constexpr before C++17 for example.

>
> 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

Re: GCC support for extensions from later standards

[Jonathan Wakely]

On Sun, 6 Aug 2023 at 20:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de>
> > 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?
>
> We use variadic templates and long long in C++98. We use a DMI in
> __gnu_cxx::__mutex even in C++98. I don't think we unconditionally use
> anything else, because we can't rely on it being available when using
> non-GCC compilers, or when compiling with -Wsystem-headers -pedantic.
> We don't use if-constexpr before C++17 for example.

Oh, but we do use __decltype in a few places.

Re: GCC support for extensions from later standards

[Nikolas Klauser]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]


On 06.08.23 12:19, Jason Merrill wrote:
> On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser 
> <nikolasklauser@berlin.de> 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

Re: GCC support for extensions from later standards

[Jakub Jelinek]

On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote:
> 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()

There are multiple problems.

cat /tmp/test.h
#pragma GCC system_header
inline int a = 1;
template <int N> int b = N;
void foo () { if constexpr (true) {} }
template <typename...A> bool bar (A... a) { return (... + a); }
struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} };
struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; };
void baz () { auto a = [](int x, int y) static { return x + y; }; }
cat /tmp/test.C
#include "/tmp/test.h"
g++ -S -std=c++11 -o /tmp/test.{s,C}

The above with GCC 13 doesn't give any warnings, but does with -Wsystem-headers:
In file included from /tmp/test.C:1:
/tmp/test.h:2:1: warning: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
    2 | inline int a = 1;
      | ^~~~~~
/tmp/test.h:3:22: warning: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions]
    3 | template <int N> int b = N;
      |                      ^
/tmp/test.h: In function ‘void foo()’:
/tmp/test.h:4:18: warning: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
    4 | void foo () { if constexpr (true) {} }
      |                  ^~~~~~~~~
/tmp/test.h: In function ‘bool bar(A ...)’:
/tmp/test.h:5:59: warning: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
    5 | template <typename...A> bool bar (A... a) { return (... + a); }
      |                                                           ^
/tmp/test.h: At global scope:
/tmp/test.h:6:29: warning: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions]
    6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} };
      |                             ^~~~~~~~
/tmp/test.h:7:34: warning: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
    7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; };
      |                                  ^~~~~~~~
/tmp/test.h: In function ‘void baz()’:
/tmp/test.h:8:41: warning: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
    8 | void baz () { auto a = [](int x, int y) static { return x + y; }; }
      |                                         ^~~~~~
and with -pedantic-errors -Wsystem-headers even errors:
./xg++ -B ./ -S /tmp/test.C -std=c++11 -pedantic-errors -Wsystem-headers
In file included from /tmp/test.C:1:
/tmp/test.h:2:1: error: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
    2 | inline int a = 1;
      | ^~~~~~
/tmp/test.h:3:22: error: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions]
    3 | template <int N> int b = N;
      |                      ^
/tmp/test.h: In function ‘void foo()’:
/tmp/test.h:4:18: error: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
    4 | void foo () { if constexpr (true) {} }
      |                  ^~~~~~~~~
/tmp/test.h: In function ‘bool bar(A ...)’:
/tmp/test.h:5:59: error: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
    5 | template <typename...A> bool bar (A... a) { return (... + a); }
      |                                                           ^
/tmp/test.h: At global scope:
/tmp/test.h:6:29: error: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions]
    6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} };
      |                             ^~~~~~~~
/tmp/test.h:7:34: error: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
    7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; };
      |                                  ^~~~~~~~
/tmp/test.h: In function ‘void baz()’:
/tmp/test.h:8:41: error: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
    8 | void baz () { auto a = [](int x, int y) static { return x + y; }; }
      |                                         ^~~~~~
(so one would need to figure out if __extension__ somewhere around would be
able to quite that up or not, or
#pragma GCC diagnostic ignored "-Wc++14-extensions" (and 17, 20 and 23).

Also, static operator () is only in GCC 13 and later, earlier versions will
error on that.  The -Wc++*-extensions separate warnings are only in GCC 12
and later, before that it will be harder to quiet the warnings selectively.
Similarly, conditional explicit is only GCC 9 and later, if constexpr and
inline vars GCC 7 and later, fold expressions GCC 6 and later, and variable
templates GCC 5 and later.  And in C++98 some of these don't work at all,
if constexpr and static lambdas (because constexpr isn't a keyword
and lambdas aren't supported altogether).

	Jakub

Re: GCC support for extensions from later standards

[Jonathan Wakely]

On Mon, 7 Aug 2023 at 14:04, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Sun, 6 Aug 2023 at 20:43, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > On Sun, 6 Aug 2023 at 20:20, Jason Merrill via Libstdc++
> > <libstdc++@gcc.gnu.org> wrote:
> > >
> > > On Wed, Aug 2, 2023 at 12:02 PM Nikolas Klauser <nikolasklauser@berlin.de>
> > > 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?
> >
> > We use variadic templates and long long in C++98. We use a DMI in
> > __gnu_cxx::__mutex even in C++98. I don't think we unconditionally use
> > anything else, because we can't rely on it being available when using
> > non-GCC compilers, or when compiling with -Wsystem-headers -pedantic.
> > We don't use if-constexpr before C++17 for example.
>
> Oh, but we do use __decltype in a few places.

I thought of another one: we use __constinit in some C++11 code. But
only inside the library, not in headers.

I've recorded these at https://gcc.gnu.org/wiki/LibstdcxxHacking for now.

Re: GCC support for extensions from later standards

[Nikolas Klauser]

Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think.

Nikolas

> On Aug 8, 2023, at 12:33 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote:
>> 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()
> 
> There are multiple problems.
> 
> cat /tmp/test.h
> #pragma GCC system_header
> inline int a = 1;
> template <int N> int b = N;
> void foo () { if constexpr (true) {} }
> template <typename...A> bool bar (A... a) { return (... + a); }
> struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} };
> struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; };
> void baz () { auto a = [](int x, int y) static { return x + y; }; }
> cat /tmp/test.C
> #include "/tmp/test.h"
> g++ -S -std=c++11 -o /tmp/test.{s,C}
> 
> The above with GCC 13 doesn't give any warnings, but does with -Wsystem-headers:
> In file included from /tmp/test.C:1:
> /tmp/test.h:2:1: warning: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
>    2 | inline int a = 1;
>      | ^~~~~~
> /tmp/test.h:3:22: warning: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions]
>    3 | template <int N> int b = N;
>      |                      ^
> /tmp/test.h: In function ‘void foo()’:
> /tmp/test.h:4:18: warning: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
>    4 | void foo () { if constexpr (true) {} }
>      |                  ^~~~~~~~~
> /tmp/test.h: In function ‘bool bar(A ...)’:
> /tmp/test.h:5:59: warning: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
>    5 | template <typename...A> bool bar (A... a) { return (... + a); }
>      |                                                           ^
> /tmp/test.h: At global scope:
> /tmp/test.h:6:29: warning: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions]
>    6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} };
>      |                             ^~~~~~~~
> /tmp/test.h:7:34: warning: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
>    7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; };
>      |                                  ^~~~~~~~
> /tmp/test.h: In function ‘void baz()’:
> /tmp/test.h:8:41: warning: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
>    8 | void baz () { auto a = [](int x, int y) static { return x + y; }; }
>      |                                         ^~~~~~
> and with -pedantic-errors -Wsystem-headers even errors:
> ./xg++ -B ./ -S /tmp/test.C -std=c++11 -pedantic-errors -Wsystem-headers
> In file included from /tmp/test.C:1:
> /tmp/test.h:2:1: error: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
>    2 | inline int a = 1;
>      | ^~~~~~
> /tmp/test.h:3:22: error: variable templates only available with ‘-std=c++14’ or ‘-std=gnu++14’ [-Wc++14-extensions]
>    3 | template <int N> int b = N;
>      |                      ^
> /tmp/test.h: In function ‘void foo()’:
> /tmp/test.h:4:18: error: ‘if constexpr’ only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
>    4 | void foo () { if constexpr (true) {} }
>      |                  ^~~~~~~~~
> /tmp/test.h: In function ‘bool bar(A ...)’:
> /tmp/test.h:5:59: error: fold-expressions only available with ‘-std=c++17’ or ‘-std=gnu++17’ [-Wc++17-extensions]
>    5 | template <typename...A> bool bar (A... a) { return (... + a); }
>      |                                                           ^
> /tmp/test.h: At global scope:
> /tmp/test.h:6:29: error: ‘explicit(bool)’ only available with ‘-std=c++20’ or ‘-std=gnu++20’ [-Wc++20-extensions]
>    6 | struct S { template <int N> explicit (N == 42) S (int (&)[N]) {} };
>      |                             ^~~~~~~~
> /tmp/test.h:7:34: error: ‘static constexpr bool T::operator()(const S&, const S&)’ may be a static member function only with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
>    7 | struct T { static constexpr bool operator () (S const &x, S const &y) { return false; }; };
>      |                                  ^~~~~~~~
> /tmp/test.h: In function ‘void baz()’:
> /tmp/test.h:8:41: error: ‘static’ only valid in lambda with ‘-std=c++23’ or ‘-std=gnu++23’ [-Wc++23-extensions]
>    8 | void baz () { auto a = [](int x, int y) static { return x + y; }; }
>      |                                         ^~~~~~
> (so one would need to figure out if __extension__ somewhere around would be
> able to quite that up or not, or
> #pragma GCC diagnostic ignored "-Wc++14-extensions" (and 17, 20 and 23).
> 
> Also, static operator () is only in GCC 13 and later, earlier versions will
> error on that.  The -Wc++*-extensions separate warnings are only in GCC 12
> and later, before that it will be harder to quiet the warnings selectively.
> Similarly, conditional explicit is only GCC 9 and later, if constexpr and
> inline vars GCC 7 and later, fold expressions GCC 6 and later, and variable
> templates GCC 5 and later.  And in C++98 some of these don't work at all,
> if constexpr and static lambdas (because constexpr isn't a keyword
> and lambdas aren't supported altogether).
> 
> 	Jakub
> 

Re: GCC support for extensions from later standards

[Jonathan Wakely]

On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote:
>
> Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think.

Can you use it in C++11 though? The body of a constexpr function must
be a single return statement, so if-constexpr isn't allowed.

You can use it in C++14 though.

Re: GCC support for extensions from later standards

[Jonathan Wakely]

On Tue, 8 Aug 2023 at 17:07, Jonathan Wakely wrote:
>
> On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote:
> >
> > Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think.
>
> Can you use it in C++11 though? The body of a constexpr function must
> be a single return statement, so if-constexpr isn't allowed.

Clang allows it with multiple warnings:

ifc.cc:3:6: warning: constexpr if is a C++17 extension [-Wc++17-extensions]
 if constexpr (sizeof(i) >= 4)
    ^
ifc.cc:3:3: warning: use of this statement in a constexpr function is
a C++14 extension [-Wc++14-extensions]
 if constexpr (sizeof(i) >= 4)
 ^
ifc.cc:8:5: warning: multiple return statements in constexpr function
is a C++14 extension [-Wc++14-extensions]
   return 0;
   ^
ifc.cc:5:5: note: previous return statement is here
   return i << 3;
   ^

But GCC gives a warning for if-constexpr and then an error for the
invalid function body:

ifc.cc: In function 'constexpr int f(int)':
ifc.cc:3:6: warning: 'if constexpr' only available with '-std=c++17'
or '-std=gnu++17' [-Wc++17-extensions]
   3 |   if constexpr (sizeof(i) >= 4)
     |      ^~~~~~~~~
ifc.cc:9:1: error: body of 'constexpr' function 'constexpr int f(int)'
not a return-statement
   9 | }
     | ^

Re: GCC support for extensions from later standards

[Nikolas Klauser]

Yes, Clang allows it. Most importantly though: you don’t have to be in a constexpr function for `if constexpr` to be useful. e.g. the Algorithms aren’t constexpr until C++20, but a lot of them have overloads for improving the algorithm based on the iterator category. Having `if constexpr` there instead of enable_ifs seems like quite a nice improvement to me. The main problem is probably that libc++ back-ports a lot of the C++11 stuff to C++03, so in these cases `if constexpr` won’t help.

> On Aug 8, 2023, at 9:10 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> 
> On Tue, 8 Aug 2023 at 17:07, Jonathan Wakely wrote:
>> 
>> On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote:
>>> 
>>> Luckily most of these aren’t problems for libc++. We only support the latest GCC. We can only use `if constexpr` in C++11, but that is already a win I think.
>> 
>> Can you use it in C++11 though? The body of a constexpr function must
>> be a single return statement, so if-constexpr isn't allowed.
> 
> Clang allows it with multiple warnings:
> 
> ifc.cc:3:6: warning: constexpr if is a C++17 extension [-Wc++17-extensions]
> if constexpr (sizeof(i) >= 4)
>    ^
> ifc.cc:3:3: warning: use of this statement in a constexpr function is
> a C++14 extension [-Wc++14-extensions]
> if constexpr (sizeof(i) >= 4)
> ^
> ifc.cc:8:5: warning: multiple return statements in constexpr function
> is a C++14 extension [-Wc++14-extensions]
>   return 0;
>   ^
> ifc.cc:5:5: note: previous return statement is here
>   return i << 3;
>   ^
> 
> But GCC gives a warning for if-constexpr and then an error for the
> invalid function body:
> 
> ifc.cc: In function 'constexpr int f(int)':
> ifc.cc:3:6: warning: 'if constexpr' only available with '-std=c++17'
> or '-std=gnu++17' [-Wc++17-extensions]
>   3 |   if constexpr (sizeof(i) >= 4)
>     |      ^~~~~~~~~
> ifc.cc:9:1: error: body of 'constexpr' function 'constexpr int f(int)'
> not a return-statement
>   9 | }
>     | ^