On Friday, 16 November 2012 at 14:50:26 UTC, Sönke Ludwig wrote:
Am 16.11.2012 15:02, schrieb monarch_dodra:
wait, no, that one
also screws up and returns based on the ASCII state of the
search character!
It doesn't screw up the result, it is meant for slicing your
string.
Just that it returns the index of the _code point_ if you pass
a non-ASCII character as the search
term and a byte index only if you pass in an ASCII char.
I'm not sure what you are trying to say? Aren't those the same?
Btw. is 'string' actually considered a RA range? After all it
provides no useful invariants apart
from str[0] == str.front - str[1] could be different from
str.popFront(); str.front.
No! String is not an RA range. It can be indexed, but
isRandomAccessRange!string is false. This is a
fundamental aspect of string, to avoid accidently breaking it.
dstring, however, is random access. You should always take
this into account for considering whether
or not it is worth converting to before operating on it. For
example: sorting the chars in a
dstring: Easy as pie. Doing it on a string: Not sure if even
possible.
In that case I got confused by the example. I thought you
wanted to make
"日本語".indexOf('本') == 3
possible again.
I did.
But that wouldn't work if indexOf operates on RA ranges. If you
do have a RA though,
how is the result of countUntil different from indexOf? If you
have an actual char-range, countUntil
should also return 3...
One of the problems is that the semantics of a char range
containing a utf payload is not very well formalized. In
particular, there is no particular rule that states that popFront
will pop an entire utf-sequence, or just a sigle char. In this
situation, we can't really say what countUntil would return...
However, it is perfectly legal to decode a forward range, so I
don't see why you wouldn't be able to explicitly search the index
in a RA range, as opposed to the amount of popFronts needed to
get there. It is two different operations, and they have been
(IMO) erroneously merged together.
One of the workarounds is to "find" instead, and then calculate
`r.length - r.find("本")`. But: 1. This is a pain to do. 2.
Doesn't work on infinite ranges (which it should).
