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

[Daniel Gibson]

Andrei Alexandrescu schrieb:
> 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.

Ok. I really should get familiar with std.algorithm and D2 in general :-)

> 
>> 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(.
> 

I'm glad to have accidentally revealed that inconsistency ;)
Probably something should be done about this, maybe by renaming one of the 
functions or something like that?

> 
> Andrei

Cheers,
- Daniel