On Tue, 11 Mar 2014 14:25:10 -0400, Johannes Pfau <nos...@example.com>
wrote:
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])
I look at it a different way -- indexes are increasing, just not
consecutive. If there is a way to say "indexes are not linear", then that
would be a good trait to expose.
For instance, think of a tree-map, which has keys that may not be
consecutive. Should you be able to slice such a container? I'd say yes.
But tree[0..5] may not get you the first 5 elements.
-Steve
