Higher level built-in strings

[DCoder]

== Quote from Michel Fortin (michel.fortin at michelf.com)'s article
> On 2010-07-20 00:31:34 -0400, Walter Bright
<newshound2 at digitalmars.com> said:
> > Steven Schveighoffer wrote:
> >> I agree here.  Anything that uses indexing to perform a linear
> >> operation is bound for the scrap heap.  But what about this:
> >>
> >> foreach(c; str)
> >>
> >> which types c as char (or immutable char), not dchar.
> >
> > Probably too late to change that one.
> Sad. That's one of the first things I tried when I first learned D
and
> the result did surprise me. I expected foreach to iterate on
characters
> (code points), not code units. Then I saw I could add 'dchar' to
get
> that behaviour and found that to be not too bad.
> The big problem here is that ranges and foreach behave
differently. A
> range that doesn't work with foreach isn't a good range. That's
even
> worse when that range is at the core of the language because it'll
look
> bad on both ranges and the language.
> As it stands now, when doing generic programming we'd have to
write
> foreach like this so it works the same with foreach as it does
with the
> range APIs, just in case the range is a string:
> 	foreach (ElementType!(typeof(range)) c; range) {}
> Something needs to change so the above always work the same as not
> specifying the type! Either foreach should be adapted or ranges
should
> let go the idea of iterating on code points for the default string
type.

I'm wondering how bad would it be introduce a schar (short char, 1
byte) type and then let char simply map to a "default" char type:
dchar, wchar, or whatever we tell the compiler. By default, char
would map to dchar.

alias char dchar;

Coupling this with implicit cast of schar/char (from imported C
code) to dchar, I think this might even help fix many such
situations.