Improving D's support of code-pages

[BCS]

Reply to Kirk,

> 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.
> 

I was looking the other way. So you are saying that only the console functions 
should have the code page stuff?

what about a dout? it goes to the console and also has a writef.

I'm not putting down your idea, I'm just looking for (and hoping not to find) 
problems.