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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Nov 11 10:57:22 PST 2010


On 11/11/10 9:52 AM, Daniel Gibson wrote:
> 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?

Yah, this is worth a bug report. Thanks.

http://d.puremagic.com/issues/show_bug.cgi?id=5201


Andrei


More information about the Digitalmars-d mailing list