[libcxx-commits] [PATCH] D92214: [libc++] Implement format_error.

[Marek Kurdej via Phabricator via libcxx-commits]

curdeius added a comment.

In D92214#2529001 <https://reviews.llvm.org/D92214#2529001>, @ldionne wrote:

> Second, allowing the library to be built either as C++17 or C++20, but provide different features depending on that, is also a pretty bad idea because then someone could link against that library, try to use some C++20 feature from the headers, and they would get a linker error. That's bad too. That's the current state of things with `char8_t` support AFAICT (@curdeius can confirm or infirm).

Indeed, not using C++20 to compile the library would prevent us from implementing any C++20 features, `char8_t` support is one example, `format_error` is another.

Just my 2 cents.
Personally, as a sort of transition before requiring C++20 to compile libc++, I'd go for allowing the build in both C++17 and C++20.
BTW, there's already some amount of `#if _LIBCPP_STD_VER > 11` and `#ifndef _LIBCPP_NO_HAS_CHAR8_T` checks in src/.
So people already can shoot themselves in a foot compiling and linking in different modes.
I'd argue that compiling the library in C++17 and using it in C++20 (and using these C++20 features) is silly.
I imagine it would be to much of a pain to guarantee that it works the other way round (compiling in C++20, using in C++17), but it should work in most of the cases.

Anyway, guarding C++20 features in src/ so as to allow the build and use in C++17 would probably be the way to go for the moment.
I know it's a maintenance burden though.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92214/new/

https://reviews.llvm.org/D92214