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.
