I disagree.
Let's call it for what it is. It is a form of interprocess communication. std::print is a just a way to interact with it. It must define something even if it's "system defined", there must be some way to be under the control of the user in order to do the right thing as a bare minimum to be useful.

If you use an API like WriteConsole the behavior is, the file will be empty. I.e. it does nothing.
And if doing nothing is an acceptable implantation, then why shouldn't it be the same implementation everywhere?

At that point the question poses itself as to why put in the effort to adopt something into the standard that does nothing.

It can't work like this, it needs an answer otherwise it's counterproductive.


________________________________
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Sunday, March 30, 2025 2:11:02 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Tymi <tymi.cpp_at_[hidden]>; Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] std::wprint/std::wprintln

> What is the expected content in “out.txt”?

Who knows? The way that shell redirection produces files is entirely
outside the scope of the standard. std::print and std::print et al.
are simply stated to forward to vprint_unicode or vprint_nonunicode.

And again, this is not introducing any new problem, just perpetuating
an existing one. You have the same problem with std::wcout.

In any case, having more Unicode support would be useful in general.
If we add overloads for std::print that work with char8_t, char16_t,
and char32_t, then we may as well add the wchar_t overload. It's
fundamentally the same problem.