Higher level built-in strings

[Andrei Alexandrescu]

Walter Bright wrote:
> Steven Schveighoffer wrote:
>> On Tue, 20 Jul 2010 14:29:43 -0400, Walter Bright 
>> <newshound2 at digitalmars.com> wrote:
>>> It's a D1 feature, and has been there since nearly the beginning.
>>
>> Since when did we care about D1 compatibility?
> 
> We care about incompatibilities that silently break code.
> 
> 
>> const, inout, array appending, final, typeof(string), TLS globals just 
>> to name a few...
>>
>> If you expect D1 code to compile fine and run on D2, you are deluding 
>> yourself.
> 
> No argument there, but we do try to avoid silent breakage.
> 
> 
>> The worst that happens is that code starts using dchar instead of 
>> char, and either a compiler error occurs and it's fixed simply by doing:
>>
>> foreach(char c; str)
>>
>> or it compiles fine because the type is never explicitly stated, and 
>> what's the big deal there?  The code just becomes more utf compatible 
>> for free :)
> 
> I don't think it's necessarily true that the user really wanted the 
> decoded character rather than the byte, or even that wanting the decoded 
> character is more likely to be desired.

Unfortunately it's inconsistent. foreach for ranges operates in terms of 
front, empty, popFront - just not for strings.

I avoid foreach in std.algorithm and in generic code.

For my money I'd be okay if foreach (c; str) wouldn't even compile - the 
user would be asked to specify the type. But if the implicit type is 
allowed, I'm afraid I believe that dchar would be the best choice.


Andrei