== Quote from Michel Fortin (michel.for...@michelf.com)'s article > On 2010-07-20 00:31:34 -0400, Walter Bright <newshou...@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.