dchar unicode phobos

[Oskar Linde]

pragma skrev:
> In article <e66hf1$otn$1 at digitaldaemon.com>, Johan Granberg says...
>> That D supports UTF is great, and by using dchar[] all Unicode code 
>> points can bee used. But phobos does not support dchar[]s adequately. 
>> (or wchar[]s for that matter) Wouldn't it bee expected of the language 
>> standard library to support all of the languages string encodings?
>>
>> Proposal: add wchar[] and dchar[] versions of the string functions in phobos
>>
>> (should this bee filed as a bug?)
> 
> Ya know, I never really thought about this, but you're right: D has three
> character types yet only has full library support for one of them.
> 
> If you ask me, there's only so many ways to go about this:
> 
> 1. Refactor std.string to use implicit templates

In http://www.digitalmars.com/d/archives/digitalmars/D/35455.html and 
other posts, I suggested a rough specification and a proof of concept 
implementation of implicit array templates that replace many of the 
functions in std.string with generic versions. If there is a definite 
interest in taking this path, I will gladly write a full generic 
replacement for std.string.

Most of the functions in my earlier suggestion were aimed at a std.array 
module, and it it hard to draw a definite line between std.string and 
std.array. My current divider is something along the line of anything 
that only makes sense for text strings are in std.string, the rest in 
std.array. One suggestion was to make std.string aliases to the generic 
functions in std.array (for instance std.string.find -> std.array.find)

> 2. Branch std.string into three modules, one for each char type
> 3. Support all three char types via overloads within std.string

> Personally, I like #1 since it would be seamless to implement, and would require
> almost exactly as much code as is in use now.  The only drawback here is centers
> around problems with distributing template code in libraries.

The template/library issues really need to be resolved.

/Oskar