Improving D's support of code-pages

[Kirk McDonald]

BCS wrote:
> Reply to Kirk,
>> Kirk McDonald wrote:
>>> 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.)
>>>
>> I should clarify this: When treating stdout like a file, it should be
>> like any other file: writing to it writes raw bytes. But when calling
>> writef, which is not treating it like a file, it should attempt to
>> encode the output into the console's default encoding.
>>
> 
> "Stream" has a writef, so you can call writef for a file.
> 
> 

But, again, files have no inherent encoding. (And if you are treating 
stdout as a file, it shouldn't have one, either.) This business about 
implicitly encoding things should be limited to the std.stdio.writef 
(and writefln, &c) function. Treating stdout as a file should be 
considered a way to get 'raw' access to stdout.

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