Request for "indexOf" undeprecation.

[monarch_dodra]

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).