[RFC] Use language extensions from future standards in libc++

[mordante]

@philnik

Relying on compiler extensions that could be removed in the future
At least according to @AaronBallman (please point out anything that I get wrong!), this is very unlikely to happen. Basically, if we want to use anything that is not documented, we should ask the clang folks if the extension is known and make them document it. If it’s documented, it’s considered very unlikely to be removed at any point. Compilers are a lot less likely to remove extensions than standard libraries are, because having these kinds of extensions is for the most part the difference between a conditional warning (informing the user that a given construct is an extension) and a conditional error (informing the user that the feature they are trying to use is not available). This makes these extensions very low maintenance for compilers.

Thanks for @ldionne to point me to this post.

Have you spoken with the GCC devs too? At least for Clang we the latest HEAD in the libc++ CI and update to snapshort every few weeks. For GCC we update only when they release, so there the breakage might be detected later. I noticed GCC-13.1 can’t be used with libc++ HEAD anymore. I haven’t had time to look into it closely, but it seems to be related to compiler builtins. As mentioned earlier, I really like to know the stance in this regard from the GCC devs. That would really help me to make an informed decision.

Personally think there is a difference between using compiler builtins and relying on undocumented extensions. The builtins are usually documented. Implementing certain library features can’t be done purely from the language. For example, certain type traits require information the compiler has. For optional builtins we typically have a library path to do it.Even when we remove it at some point it can be easily revived from the history.