Improving D's support of code-pages

[Kirk McDonald]

BCS wrote:
> 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.
> 
> 

The functions encode() and decode() are available on their own. If you 
want to explicitly encode something you're writing to a file, you can 
simply say e.g.:

somefile.write(encode(some_utf8_string, "cp437"));

Only the console functions would call this /implicitly/, since only they 
/have/ an implicit encoding (which is the console's encoding as reported 
by the OS). Since you might not always want to encode the stuff you 
print out, you should be able to use std.cstream.dout.writef() to get 
around this.

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