"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
