Does this complete the implementation of P0482R6? If yes, please update the status page and feature test macros. Otherwise, what is still missing?

I think this should also be guarded with _LIBCPP_STD_VER >= 20.

As a C++ implementation we are interested in which C++ version something got added. So please use that version instead of in which C version something got added. Same for the rest of the synopsis.

I expect that this does complete P0482R6, but I'll double check, report back, and update the status page accordingly.

With regard to updating feature test macros, I don't think there is anything to be done. P0482R6 only specifies the single __cpp_lib_char8_t feature test macro for the library. libc++ already defines that macro based on the prior P0482R6 implementation efforts and the recent implementation of P1423 bumped its value. Though P0482R6 is not explicit about this (either in prose or wording), it can be inferred that the feature test macro is not applicable to these declarations as it is not required to be defined by the <cuchar> or uchar.h headers. Additionally, since c8rtomb() and mbrtoc8() are expected to be provided by the C library, entangling the macro definition with the availability of those declarations would get messy. This is consistent with the behavior of libstdcxx.

That is an option, but leads to scenarios where the declarations are available in the global namespace via uchar.h but not in the std namespace via <cuchar>. I thought it made more sense to keep these in sync.

At present, libc++ omits the other char8_t related declarations (e.g., u8string) in C++20 mode when char8_t support is disabled (of course) but likewise omits them in pre-C++20 modes when char8_t support is enabled. What I would prefer to do (in a separate patch) is to match the libstdcxx behavior of declaring all of the char8_t related declarations based on char8_t enablement rather than on the C++ standard version. This would give users more flexibility for evaluating and addressing`char8_t` related migration concerns before migrating to C++20.

Things get kind of messy here. The declarations in <cuchar> were added in C++20. Since C++20 depends on C17, no version of C++ will require the uchar.h declarations until a future C++ standard that is based on C23 (which will be required by ISO to happen for C++26). Our choices are:

1. Omit these declarations pending a future C++ standard.
2. Annotate these declarations as "since C++20" since that will reflect existing practice (e.g., glibc will declare them in uchar.h in C++20 mode) and the declarations are needed to satisfy the std namespace declarations in <cuchar>.
3. Optimistically annotate these as "since C++26" or "expected in C++26".

I'm inclined toward option 2.

I audited the P0482R6 wording and found evidence of declarations for everything except the polymorphic allocator related declarations:

• std::pmr::u8string
• std::hash<std::pmr::u8string>

This appears to be expected given that P0220R1 is still listed as in-progress in libcxx/docs/Status/Cxx17Papers.csv and that https://reviews.llvm.org/D89057 is still awaiting revisions and approvals.

I think the current state plus this patch suffices to consider P0482R6 complete. I'll update the status page to mark it complete with a note that the missing declarations are pending completion of polymorphic allocator support.

Then we can't consider it complete yet. It would be great though if you could mark it as Partial and add a note that only the std::pmr::u8string alias and std::hash<std::pmr::u8string> are missing.

Hmm. Having the declarations in uchar.h but not in cuchar would indeed be quite weird. OTOH having the declarations pre-C++20 would be an extension in the C library, which we might not want to support. I also suspect that you will find quite strong opposition to enabling char8_t pre-C++20. We are quite anti-extensions and have even removed a number of them over the last years. @ldionne Do you have any thoughts here?

Yes, options 2 sounds like the right thing.

That works; will do.

@ldionne, could you please share your thoughts on whether the std::c8rtomb() and std::mbrtoc8() declarations should be restricted to C++20 and later or provided consistent with the corresponding C declarations in the global namespace?

My preference would be to be strict (and hence not include them before C++20). That being said, it seems like we have a strong precedent everywhere in our C compatibility headers to include functions inside std:: whenever they are provided by the underlying C library. So I think the current approach is OK.

Is there a reason why we even need _LIBCPP_HAS_NO_C8RTOMB_MBRTOC8 at all? We have _LIBCPP_USING_IF_EXIST to eliminate the need for exactly this sort of stuff. Of course GCC doesn't implement it, however it would still work when compiling using Clang on a platform that uses glibc.

My first patch relied solely on _LIBCPP_USING_IF_EXIST, but that lead to CI build failures as can be seen at https://reviews.llvm.org/harbormaster/unit/view/4733761/. It seems that all such unconditional uses of _LIBCPP_USING_IF_EXIST are only exercised in CI builds where the dependent declarations are present. I followed the precedent that appears to be in place for other such problematic cases; see _LIBCPP_HAS_NO_FGETPOS_FSETPOS for example.

_LIBCPP_HAS_NO_FGETPOS_FSETPOS predates the existence of _LIBCPP_USING_IF_EXIST. https://reviews.llvm.org/harbormaster/unit/view/4733761/ is a failure on GCC, which I would indeed expect because GCC does not implement the using_if_exists attribute.

I guess my question is: would you see an issue with supporting <cuchar> only on Clang, or on GCC when a suitable Glibc is present? Glibc 2.36 is pretty recent, so that would mean only on Clang at least for some time. IMO this is acceptable since libc++'s primary compiler is Clang.

I don't have a sense of how many people use libc++ with gcc. Since libc++'s <cuchar> does work with gcc today, removing support for it could legitimately be considered a regression.

A solution that limits <cuchar> support depending on the presence of a suitable Glibc release would, I think, look quite similar to what is implemented in this patch, so I don't see that as being an improvement. I looked for existing cases where a libc++ header is explicitly not supported for use with gcc and didn't find one. Are there any such existing cases?