I understand all that. But it is definitely possible to make an overload
that accepts std::wostream, since there already exists with std::ostream. I
only work with Windows specific code, and I consider wprint to be a
necessity in C++.

On Sun, 30 Mar 2025, 12:39 Tiago Freire, <tmiguelf_at_[hidden]> wrote:

> 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_[hidden]> 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]> 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.
>
>
>