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

Daniel Gibson metalcaedes at gmail.com
Thu Nov 11 09:25:31 PST 2010


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
string substring(string s, size_t beg, size_t end) // "logical slice" - from 
code point number beg to code point number end

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


More information about the Digitalmars-d mailing list