[review] new string type

[Ellery Newcomer]

On 12/01/2010 03:35 PM, Steven Schveighoffer wrote:
> On Tue, 30 Nov 2010 18:31:05 -0500, Ellery Newcomer
>>
>> There definitely is value in being able to index and slice into utf
>> strings without resulting in invalid utf, but I think the fact that it
>> indexes on code unit and returns code point is sufficiently strange
>> that it qualifies as abuse of operator overloading.
>
> Maybe :) The other alternative is to throw an exception if you try to
> access a code unit that is not the beginning of a code point.
>
> That might actually be less weird, I'll try doing that on the next
> iteration.

in my mind, the problem isn't so much indexing an intermediate code unit 
gets you earlier code units (it's a little strange, and I'm not sure 
whether greater strictness would be better - on the one hand, less 
strictness would be more tolerant of bugs and make it that much more 
difficult to detect them, but on the other hand if you were doing 
something like getting a random or approximate slice into your string, 
less strictness would mean that much less annoyance, though I have no 
idea why you would want to do that) as it is just the difference between 
the two and the confusion that it's bound to cause the noobies.

>
> I find that iteration over string characters using index is a very rare
> thing anyways, you either use foreach, which should give you dchars, or
> you use something like find, which should never give you an invalid index.
>
> -Steve

find was the counterargument I had in mind for keeping the operator 
overload, as something like

s[find(s,'\u2729') .. s.codeUnits]

is just a bit better than

s.codePointSliceAt(find(s,'\u2729'), s.codeUnits);

I really don't know.

One thing that strikes me, though, if you're going to keep opIndex, is 
that being able to do

foreach(size_t codeuniti, dchar c; s){

}

would be nice. Actually, it looks like you can do that with current strings.