A function could just forward a string to another function or to a platform API, without assuming any encoding.   -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 31.08.2025 15:56 Betreff:Re: [std-proposals] charN_t (was: TBAA and extended floating-point types) An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Sat, Aug 30, 2025 at 4:18 PM zxuiji via Std-Proposals <std-proposals_at_[hidden]> wrote: > > I'm not saying APIs can't assume unicode usage of those types, that'd be documented anyways. What I'm saying is that the default assumption that the type can only be used for unicode is wrong. For example could make APIs that specifically use char16_t for wrapping iconv() and the MultByteToWideChar so that older encodings can be used during compile time and still have a consistent ABI across systems instead of the 2 vs 4 bytes crap we have with wchar_t. I'm not sure I understand the difference with regard to these assumptions: default assumptions *are* API assumptions. That APIs respect those assumptions is how they became the default. The C++ standard's APIs when using these types assume their encoding. The standard library should not violate its own API assumptions. *You* can do whatever you want. But the standard created those types *specifically* to have those assumptions. It wasn't just about having a sized integer. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals