I know that this is something that looks like a good idea, but isn't, once you understand the underlying details.

This would not make for portable code, it would at most only work on Windows and even at that not universally.
I’m assuming that what you are trying to use is the (W)ide versions of Windows API’s such as “WriteConsoleW”.

First things first this would never work on Linux because the only means of output is an 8bit per character interface, and wchar_t can be 32bit per character (or 16bit depending on compiler options), so you would need to convert a text sequence from wchar_t to a char type.
What is the encoding of text in “wchar_t” sequence?
The encoding of “char” is not even consistent other than “system encoding” (whatever that means), “wchar_t” is definitely not defined. Good luck sorting that one out!

You would think that the encoding of wchar_t would at least be more defined on Windows, surely it must be UTF-16 right? Wrong! It’s not! It is not only not consistent from system to system, it is not consistent with application running in the same machine, even worse; an application could change at runtime what “wchar_t” means when you pass it to “WriteConsoleW”, it’s a feature, please see “SetConsoleCP”.

Now, why is it named “Write”-“Console” and not just “Write”-“Out”? And how is it possible that “WriteConsoleW” is able to pass 16bit per character streams when cout is definitely 8bit per character stream?
Because they are actually 2 separate streams bundled in the same output interface! (cout)
“WriteConsoleW” only works when the parent process has created a special “Console” buffer output (which a console does) which has the twin streams, and when you use “WriteConsoleW” it asks to use the alternative 16bit stream bundled on the output channel.
If you tried to use a pipe (for example to write out to a file) and the application “WriteConsoleW” is used, “WriteConsoleW” will fail (because the twin 16bit stream doesn’t exist) and none of those messages will be seen.

“WriteConsoleW” is only meant to work if an application is attached to a console (or a console like application, that specifically provides console like features).
It is not meant for general use applications.

This is a mess. To much operating system specific behavior. You don’t want to touch it.



________________________________
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> on behalf of Tymi via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, March 30, 2025 11:30:31 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Tymi <tymi.cpp_at_[hidden]>
Subject: Re: [std-proposals] std::wprint/std::wprintln

I mean, I am up to making std::print just accept std::wformat_ string but I am aware many members would not like that...

On Sun, Mar 30, 2025 at 11:19 AM Tymi <tymi.cpp_at_[hidden]<mailto:tymi.cpp_at_[hidden]>> wrote:
wide string support for std::print/std::println would be neat. I need it in my projects.
I can write a proposal & possible implementation if enough people support this!

tymi.