[review] new string type

[Steven Wawryk]

On 02/12/10 12:43, Ellery Newcomer wrote:
> On 12/01/2010 03:35 PM, Steven Schveighoffer wrote:
>>
>> 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.

I don't like either.  I'd prefer (from std.algorithm)

s = find(s, '\u2729');

I still don't see a need for any random-access methods, including 
slicing, on the code-point range.

The ability to convert back and forth between the string_t and T[] would 
be useful to allow the user to choose between random-access code-unit 
range and bidirectional code-point range (or grapheme/glyph/etc).  For 
example a T[] accessor property and an opAssign from a T[].

So if there are efficiencies to be had with random-access (and slicing), 
then the user could choose

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

Are there any other reasons to slice on a code-point range?  Or have any 
capabilities beyond a bidirectional range?  Unless there are compelling 
reasons, I'd have to say that slicing and indexing on the code-point 
level is not much more than a hack.