On Sun, 30 Mar 2025, 12:14 Tymi via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> I can add std::wprint to my C++ implementation as a language extension I
> guess...
>

Why not just add it to your own namespace?


Also really, why can't it just fallback to converting to UTF8 on
> unsupported systems??
>
> On Sun, 30 Mar 2025, 13:11 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
>
>> Then that’s very easy, we can make “std::wprint[ln](L"Hi");” a no-op,
>> i.e. it does nothing.
>>
>> Perfectly consistent behavior.
>>
>>
>>
>> But I doubt that is what you want.
>>
>> You want it to do something, you want it to do a very specific thing, you
>> want it to print out a message, and if you do that you expect to be able to
>> read said message. And now we are back to questions related to “what is the
>> encoding” and “how will you make it work and in what circumstances does it
>> work”. You may be fine with “I don’t care, just do something” (to which I
>> would argue, doing nothing is a something). But I’m not!
>>
>>
>>
>> You are free to pursuit this but be aware that these questions will come
>> back to you.
>>
>>
>>
>> I have tried to go down this road, didn’t even made it to a proposal.
>> There’s nothing that stops you right now from trying to implement these
>> features as a library, putting this in the standard will not magically make
>> the operating system have an interface that it doesn’t currently support,
>> it has to be a library feature, so you can start writing it today.
>>
>> So, you should try it as an exercise, make a portable library. That’s how
>> I started, that’s how I stopped.
>>
>>
>>
>> *From:* Tymi <tymi.cpp_at_[hidden]>
>> *Sent:* Sunday, March 30, 2025 12:55 PM
>> *To:* Tiago Freire <tmiguelf_at_[hidden]>
>> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>>
>>
>>
>> It is messy I know. Not hopeless though. Why can't std::wprint fallback
>> to std::wcout on linux systems? It wouldn't be not compliant. If you think
>> I am trying to replicate std::print because I think Windows UTF16 support
>> is better, then this is wrong. I want an interface that supports wide
>> string formatting with a print function. I don't care if it converts my
>> string to UTF8 and prints that even. As long as I can write
>> `std::[w]print[ln](L"Hi");` I am fine with it.
>>
>>
>>
>> On Sun, 30 Mar 2025, 12:52 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
>>
>> They do. And I would strongly argue that they shouldn’t.
>>
>> What is the encoding of std::wformat_string again?.... What should it
>> even output?
>>
>> Not everything in the standard are roses, this is one of the parts that
>> is extremely messy.
>>
>>
>>
>> I understand that at a distance it looks good, it sounds like a good
>> idea, I’ve tried to do something consistent in this field too, but I went
>> mad trying to clean this mess. I came to the conclusion that the best
>> solution is not to.
>>
>> The best solution is to throw it all way and just start from scratch.
>> It’s hopeless.
>>
>>
>>
>>
>>
>> *From:* Tymi <tymi.cpp_at_[hidden]>
>> *Sent:* Sunday, March 30, 2025 12:45 PM
>> *To:* Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]
>> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>>
>>
>>
>> std::wcout, std::wformat_string, std::format wide string overloads and
>> many more already exist. wprint is the only one missing anyway.
>>
>>
>>
>> On Sun, 30 Mar 2025, 12:41 Tymi, <tymi.cpp_at_[hidden]> wrote:
>>
>> 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.
>>
>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>