Improving D's support of code-pages

[Kirk McDonald]

Walter Bright wrote:
> Kirk McDonald wrote:
> 
>> Walter Bright wrote:
>>
>>> There's a big problem with this - what if the output is being sent to 
>>> a file?
>>
>>
>> Files have no inherent encoding, only the console does. In this way, 
>> writing to a file is different than writing to the console. The user 
>> must explcitly provide an encoding when writing to a file; or, if they 
>> are writing a char[], wchar[], or dchar[], the encoding will be UTF-8, 
>> -16, or -32. (Writing a char[] implies an encoding, while writing a 
>> ubyte[] does not.)
> 
> 
> 
> The problem is that whatever is sent to a file should be the same as 
> what is sent to the screen. Consider if stdout is piped to another 
> application - what should happen?

Let's say there's a function get_console_encoding() which returns the 
console's current encoding. I'm simply proposing that this:

char[] str = something();
std.stdio.writefln(str);

Should end up being equivalent to this:

std.cstream.dout.writefln(encode(str, get_console_encoding()));

So, to answer your question, if you use std.stdio.writefln, you will 
send a string encoded in the console's default encoding to the other 
application's stdin. This is the encoding the other application should 
be expecting, anyway (unless it isn't; code pages are annoying like that).

In any event, if you explicitly want to output something in a particular 
encoding, this /will/ work:

std.stdio.writefln(encode(str, whatever));

This is because encode() returns a ubyte[], and writefln should print 
the data in ubyte[]s directly, as I suggested in my original post for 
this precise reason.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org