Am Tue, 11 Mar 2014 14:02:26 -0400 schrieb "Steven Schveighoffer" <schvei...@yahoo.com>:
> A previous poster brings up this incorrect code: > > auto index = countUntil(str, "xyz"); > auto newstr = str[index..$]; > > But it can easily be done this way also: > > auto index = indexOf(str, "xyz"); > auto codepts = walkLength(str[0..index]); > auto newstr = str[index..$]; > > Given how D works, I think it would be very costly and near > impossible to somehow make the incorrect slice operation statically > rejected. One simply has to be trained what a code point is, and what > a code unit is. HOWEVER, for the most part, nobody needs to care. > Strings work fine without having to randomly access specific code > points or slice based on them. Using indexes works just fine. > > -Steve Yes, you can workaround the count problem, but then it is not "consistent across all uses of the string". What if the above code was a generic template written for arrays? Then it silently fails for strings and you have to special case it. I think the problem here is that if ranges / algorithms have to work on the same data type as slicing/indexing. If .front returns code units, then indexing/slicing should be done with code units. If it returns code points then slicing has to happen on code points for consistency or it should be disallowed. (Slicing on code units is important - no doubt. But it is error prone and should be explicit in some way: string.sliceCP(a, b) or string.representation[a...b])