[libc++] No library support for `char8_t` if compiled without C++20 but with `-fchar8_t`

[MitalAshok]

Currently, _LIBCPP_HAS_NO_CHAR8_T is always defined if not compiled with -std=c++20 or above:

llvm-project/libcxx/include/__config

Lines 702 to 704 in 3ab2247

	# if _LIBCPP_STD_VER <= 17 || !defined(__cpp_char8_t)
	# define _LIBCPP_HAS_NO_CHAR8_T
	# endif

But both Clang and GCC allow char8_t in older standards with the -fchar8_t flag: https://godbolt.org/z/ePcrqvWsa

Someone specifying -fchar8_t presumably is going to use char8_t consistently even before C++20, so it makes sense to allow using library facilities for char8_t. One problem I can think of is that some names (like u8string) aren't reserved in C++17, but someone using -fchar8_t should know not to use them. Plus libstdc++ supports it.

[ldionne]

Libc++ generally strives to stick to the letter of the Standard as much as possible, since doing otherwise creates loads of problems. For example, proper interoperation with char8_t might require pulling in other features into previous standard modes, and that's not a path we want to go down.

So my first reaction to this would be that we don't want to support this, basically.

[MitalAshok]

Yeah that makes sense.

However, I don't think it would be too harmful to scale back to just add std::char_traits<char8_t>. It would be a standards-conforming extension as char8_t is an extension type, and users can use std::basic_string<char8_t>/std::basic_ostream<char8_t>/std::basic_string_view<char8_t> and be ABI compatible with C++20. std::char_traits<char8_t> is the only pain point.

(This might be a big implementation burden, and you don't want to end up in a situation like libstdc++ that supports std::basic_string<unsigned char> and std::basic_string<std::byte>)

There doesn't appear to be a big userbase for -std=c++17 -fchar8_t, so not really a big issue either way.

[philnik777]

IIUC this is a flag to ease upgrading to C++20, so I don't really see why we'd want to support -fchar8_t in previous language modes. To upgrade you can use -std=c++20 -fno-char8_t, but why would you want e.g. -std=c++17 -fchar8_t? @AaronBallman do you have any thoughts on this?

[philnik777]

(BTW this is also a case where https://discourse.llvm.org/t/rfc-require-discussion-of-impact-to-monorepo-stakeholders-when-adding-new-clang-extensions/79613 would have been a good idea - thanks for adding that requirement Aaron!)

[MitalAshok]

It appears something similar was being done here: https://reviews.llvm.org/D92212, which was abandoned.

Now I doubt -std=c++17 -fchar_t is intentional. It was added in 3a8244d and only says -fchar8_t is basically the way to get -std=c++20. #55373 talks about -std=c18 -fchar8_t and -std=c23 -fchar8_t, which seem likewise unintentional and might be disabled in the future. I guess it wouldn't make sense to support an unintentional extension.

[ldionne]

Thanks for the discussion folks! Tentatively closing since the consensus appears to be that this isn't worth doing, but please reopen if I misread this or if more discussion is needed.

[frederick-vs-ja]

but why would you want e.g. -std=c++17 -fchar8_t

FYI, MSVC STL supports such a dialect as requested by @MahmoudGSaleh, see microsoft/STL#2106.