Proposal for fixing dchar ranges

[monarch_dodra]

On Tuesday, 11 March 2014 at 18:26:36 UTC, Johannes Pfau wrote:
> 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 think it is import to remember that in terms of 
ranges/algorithms, strings are not indexable, nor sliceable 
ranges.

The "only way" to generically slice a string in generic code, is 
to explicitly test that a range is actually a string, and then 
knowingly call an "internal primitive" that is NOT a part of the 
range traits.

So slicing/indexing *is* already disallowed, in terms of 
range/algorithms anyways.