Narrow string is not a random access range

[Jonathan M Davis]

On Wednesday, October 24, 2012 14:18:04 mist wrote:
> What about a compromise - turning this proposal upside down and
> requiring something like "utfstring".decode to operate on
> symbols? ( There is front & Co in std.array but I am thinking of
> more tightly coupled to string ) It would have removed necessity
> of copy-pasting the very same checks for all algorithms and move
> decision about usage of code points vs code units to user side.
> Yes, it is does not prohibit a lot if senseless operations, but
> at least it is consistent approach.

I'm afraid that I don't understand what you're proposing.

> I personally believe that not
> being able to understand what to await from basic
> algorithm/operation applied to string (without looking at lib
> source code) is much more difficult sitation then necessity to
> properly understand unicode.

Well, to use ranges in general, you need to understand hasLength, hasSlicing, 
isRandomAccessRange, etc., and you need to understand what it means when 
template constraints fail based on those templates. That being the case, 
strings are no different from any other range in that if they fail to 
instantiate with a particular function, then you need to look at the template 
constraints and see what the function requires, and sometimes you just can't 
know without looking at the template constraints, because it's not always 
obvious which range operations a particular function will require just based 
on what it's supposed to do. The main issue is understanding which range-based 
operations arrays have but which narrow strings don't. Then when a template 
fails to instantiate because a string isn't random access or sliceable or 
whatnot, you understand why rather than getting totally confused about int[] 
working and char[] not working.

- Jonathan M Davis