Proposal for fixing dchar ranges

[Steven Schveighoffer]

On Tue, 11 Mar 2014 14:25:10 -0400, Johannes Pfau <nospam at 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