why a part of D community do not want go to D2 ?

[Andrei Alexandrescu]

On 11/11/10 9:25 AM, Daniel Gibson wrote:
> Jonathan M Davis schrieb:
>> On Wednesday, November 10, 2010 14:52:10 Jesse Phillips wrote:
>>> Walter Bright Wrote:
>>>> dsimcha wrote:
>>>>> Libraries need to make the
>>>>> simple use cases sufficiently simple that people aren't tempted to
>>>>> roll
>>>>> their own.
>>>> Hear hear. For example, one of the goals with D strings was to make
>>>> them
>>>> so good that people wouldn't invent their own string classes.
>>> And yet we still get those that want a class, or even limit the
>>> capability
>>> of arrays so that a class is more appealing. (Had a friend that hated
>>> the
>>> idea that D went back to array of characters, then he saw that arrays
>>> could actually do stuff)
>>
>> Well, of course his first reaction was negative. Arrays suck in other
>> languages in comparison to D. Having strings be arrays in C is
>> horrible. I'd be annoyed to have strings be arrays if you were using
>> Java arrays, and they're a definite improvement over C - if nothing
>> else because they know their length. Strings as arrays work in D
>> precisely because D arrays are so awesome. I've never used another
>> language which had arrays which were even close to as awesome as the
>> ones in D.
>>
>> - Jonathan M Davis
>
> The only possible source of confusion may be that slicing is only safe
> with dchar[]. (But still may work with char[] as long as you're only
> using ASCII characters, so the error may not be obvious)
>
> Of course I don't want to propose to change that because it makes
> perfect sense the way it is, because in many situations you want to
> know, how long the string physically is (how many bytes), so any hack to
> splice by logical characters instead of physical characters would result
> in a terrible mess.
>
> But this is something a string-class with .substring(beg, end),
> .logLength, .physLength and stuff like that could fix, because these
> differences were more obvious.
>
> But then again, having the following functions in std.string may suffice:
>
> size_t logLength(string s) // logical length in code points

That would be walkLength.

> string substring(string s, size_t beg, size_t end) // "logical slice" -
> from code point number beg to code point number end

That's not implemented and I don't think it would be useful. Usually 
when I want a substring, the calculations up to that point indicate the 
code _unit_ I'm at.

> On the other hand those wouldn't play nice with the existing functions
> like indexOf etc :/

Hm, I just noticed a problem. std.algorithm.indexOf returns logical 
position because it uses the forward range interface, and 
std.string.indexOf returns the physical position :o(.


Andrei