Re: unicode characters are not printed correctly on the windows command line?

[Symphony via Digitalmars-d-learn]

On Monday, 23 December 2019 at 15:34:13 UTC, Steven Schveighoffer 
wrote:
I really appreciate the enthusiasm here, but at the risk of 
being cynical, I see little chance that this gets accepted. 
Before you spend any time on actual code, a DIP is going to be 
required, as this would be a huge change to the language. I'm 
sure you have a lot of time, but I don't want you to waste it 
on something that is likely to be rejected.

If you still want to proceed, even at the risk of doing a lot 
of work for nothing (or at least, a lot of work that ends up 
being just on code.dlang.org instead of Phobos), I can tell you 
what my plan was:

1. std.stdio.File was going to be set up to source from either 
an iopipe-based io subsystem, or a FILE *.

2. The standard handles would be open with the default C FILE * 
standard handles as the source/target.

3. Upon using any "d-like" features on a File that is sourced 
from a FILE * (i.e. byline), the File would be switched to a 
newly-created iopipe-based source. The theory is here, that 
once you do something like this, you commit to using D on that, 
and I'd much rather use a higher performing subsystem (iopipe 
beats Phobos right now by 2x performance). This only counts for 
things that make the File unusable on its own anyway. So 
writefln and writeln would NOT switch the source, neither would 
lockingTextReader/Writer.

4. Any new File that is opened using any constructor other than 
passing in a FILE * will be opened with an iopipe source.

5. The iopipe and io subsystems can be used directly instead of 
with File, as a lot of times you don't need that overhead.

Let me know if you decide to do this, I can guide you.

-Steve
Pardon my ignorance, but wouldn't the inclusion of a std.io (e.g. 
Martin Nowak's io library) into Phobos be an easier and cleaner 
move? Other Phobos modules that require std.stdio could be 
gradually changed so that they use std.io instead. There would be 
the issue of two coexisting IO libraries in std, but issuing some 
warnings whenever std.stdio is imported wouldn't be too bad in my 
view; that is unless Mr. Bright's opposition is the main blocker.