D's confusing strings (was Re: D on hackernews)

[Christophe]

"Jonathan M Davis" , dans le message (digitalmars.D:144922), a écrit :
> 1. drop says nothing about slicing.
> 2. popFrontN (which drop calls) says that it slices for ranges that support 
> slicing. Strings do not unless they're arrays of dchar.
> 
> Yes, hasSlicing should probably be clearer about narrow strings, but that has 
> nothing to do with drop.

I never said there was a problem with drop.

> char a = 'ä';
> 
> shouldn't even be legal. It's a compiler bug.

I figured that out.
I wanted to show that a char couldn't hold a code point, but I was too 
fast and confused code points with code units.

>> Dealing with utfencoded strings is less efficient, but there is a number
>> of algorithms that can be optimized for utfencoded strings, like copying
>> or finding an ascii char in a string. Unfortunately, there is no
>> practical way to do this with the current range API.

Maybe there should be a way for the designer of a class to provide an 
overload for some algorithms, like forwarding to myClass.algorithm for 
instance. The problem is that this is an open door for unvoluntary 
hacking.

Oh, I just noticed I'm actually answering to myself. Thinking out loud, 
am I ?

> [...]

After having read all of you, I have no problems with string being a 
lazy range of dchar. But I have a problem with immutable(char)[] being 
lazy range of dchar (ie not being a array), and I have a problem with 
string being immutable(char)[] (ie providing length opIndex and 
opSlice).

Thanks
-- 
Christophe