Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we consistently use __cpp_char8_t or __cpp_lib_char8_t? #4400

Closed
frederick-vs-ja opened this issue Feb 17, 2024 · 2 comments
Closed
Labels
question Further information is requested resolved Successfully resolved without a commit

Comments

@frederick-vs-ja
Copy link
Contributor

MSVC STL supports C++20/23 without char8_t and C++14/17 with char8_t dialects (see #2748). As a result, availability of some components is controlled by feature-test macros rather than standard revisions.

However, there doesn't seem a general whether the predefined feature-test macro __cpp_char8_t or the library feature-test macro __cpp_lib_char8_t should be used for controlling, and both of them are currently used.

STL/stl/inc/xstring

Lines 482 to 485 in c53ac59

#ifdef __cpp_char8_t
template <>
struct char_traits<char8_t> : _Narrow_char_traits<char8_t, unsigned int> {};
#endif // defined(__cpp_char8_t)

STL/stl/inc/xstring

Lines 1789 to 1791 in c53ac59

#ifdef __cpp_lib_char8_t
_EXPORT_STD using u8string_view = basic_string_view<char8_t>;
#endif // defined(__cpp_lib_char8_t)

Presumably we should consistently use one for controlling.

@frederick-vs-ja frederick-vs-ja added the question Further information is requested label Feb 17, 2024
@StephanTLavavej
Copy link
Member

There was a rationale behind this scheme. I'll get more details for you.

@StephanTLavavej
Copy link
Member

The rationale is that /Zc:char8_t is (perhaps surprisingly) available as an opt-in mode in C++14/17. In the STL, we enable minimal recognition of C++14/17 with char8_t by inspecting the compiler macro __cpp_char8_t. This is usually in always-available components that need to react to char8_t's presence, e.g. the type traits like is_integral_v:

STL/stl/inc/xtr1common

Lines 187 to 193 in c53ac59

_EXPORT_STD template <class _Ty>
_INLINE_VAR constexpr bool is_integral_v = _Is_any_of_v<remove_cv_t<_Ty>, bool, char, signed char, unsigned char,
wchar_t,
#ifdef __cpp_char8_t
char8_t,
#endif // defined(__cpp_char8_t)
char16_t, char32_t, short, unsigned short, int, unsigned int, long, unsigned long, long long, unsigned long long>;

However, we still don't want to enable C++20 library tech downlevel, so that's what __cpp_lib_char8_t guards. We would usually use plain _HAS_CXX20 guards, except that /Zc:char8_t- acts as an opt-out here. So that's why library tech like u8string_view is guarded this way:

STL/stl/inc/xstring

Lines 1789 to 1791 in c53ac59

#ifdef __cpp_lib_char8_t
_EXPORT_STD using u8string_view = basic_string_view<char8_t>;
#endif // defined(__cpp_lib_char8_t)

@StephanTLavavej StephanTLavavej added the resolved Successfully resolved without a commit label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested resolved Successfully resolved without a commit
Projects
None yet
Development

No branches or pull requests

2 participants