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.
