`charseek`: replace `thisind`, `nextind` and `prevind`?

[StefanKarpinski]

The string index arithmetic API has grown organically over time and while it works, it feels a bit less minimal than it could be – three functions to navigate between the characters in a function is more than one might hope for. By comparison, relative array index navigation can be done entirely with a single operation: +. I'd like to propose a single charseek function to replace thisind, nextind and prevind:

charseek(s::AbstractString, i::Integer, n::Integer)

Advance to the index of a character in s relative to the character in s that index i points into. The index i does not need to be the lead index of a character but the returned index is guaranteed to be the index of a character (or out of bounds).

This allows us to replace the current functions like so:

• thisind(s, i) => charseek(s, i, 0)
• nextind(s, i, n) => charseek(s, i, n)
• prevind(s, i, n) =>
  • charseek(s, i, -n) if you know that i is valid
  • charseek(s, i, 1-n) if you know that i is invalid
  • charseek(s, charseek(s, i, 1), -n) if i might be valid or invalid

This function obeys nice identities, such as:

• charseek(s, charseek(s, i, m), n) == charseek(s, i, m + n)
• charseek(s, i, -n) < i < charseek(s, i, n) for n > 0

On top of #24999 this is a simulation of charseek if someone wants to try it out:

charseek(s::AbstractString, i::Integer, n::Integer) =
    n < 0 ? prevind(s, i, (checkbounds(Bool,s,i) && !isvalid(s,i))-n) :
    n > 0 ? nextind(s, i, n) : thisind(s, i)

[StefanKarpinski]

I'm not sure what if anything the n argument should default to: 0 would mean that the default behavior of charseek(s, i) would be thisind(s, i) while 1 would mean nextind(s, i).

[kmsquire]

If there’ no obvious default, then maybe it should just be required?

[StefanKarpinski]

A less drastic overhaul would be to just extend nextind to negative character offsets, replace thisind(s, i) with nextind(s, i, 0) and keep prevind(s, i, n) as it is already, maybe also extending it to negative indices. But I still would kind of prefer just a single function for this.

[nalimilan]

nextind and prevind are nice to have as completely generic functions for all indexable collections. For example, they can be used with CartesianIndex, where + 1 doesn't work. They could also be useful in combination with findnext/findprev if these accepted cartesian indices in addition to linear indices.

[StefanKarpinski]

Fair enough, although in that case the encoding synchronization feature for strings could be decoupled from the index arithmetic behavior. The thing that kind of bothers me about nextind and prevind is the difference in behavior for invalid indices. That's why the simulation of charseek in terms of prevind and nextind is so tricky (and vice versa, the deprecation of prevind in terms of charseek is complex compared to thisind and nextind).

[StefanKarpinski]

For other kinds of index computations do we really want separate forward and backward functions? Or should we have a single seekind? If there are separate functions, do you allow negative seek values to go in the other direction or do you force people to use separate functions with nonnegative argument? If we had a general seekind function it could be the name of charseek above for strings and be the bidirectional index seeking function for arrays and other containers.

[StefanKarpinski]

It's a bit unfortunate that the I/O seek function is absolute only. Perhaps we should split that into seekabs and seekrel or something since those are both viable actions for I/O streams. Of course then there's the issue of whether you're seeking in terms of bytes or characters – I/O stuff is all done in terms of bytes whereas the string functions should do characters to be useful.

[vtjnash]

For IO, we call those seek, skip, and seekend, respectively.

[StefanKarpinski]

Ah, that's helpful. Does skip allow negative values to go backwards?

[vtjnash]

Does skip allow negative values to go backwards?

Yes

[StefanKarpinski]

That might suggest charseek(s, n) as a replacement for chr2ind(s, i) and charskip(s, n) as the name for what I was calling charseek (seekend doesn't really make sense for strings). However, these are fairly different APIs since streams are stateful and keep the cursor internally whereas the string API is an external state arithmetic API.

[stevengj]

One thing to keep in mind is that we want to make sure that the common case of nextind(s,i) and prevind(s,i) is as fast as possible. Using charseek(s,i,±1) seems like it could be slower unless the compiler inlines and constant-folds etc, but maybe LLVM is good enough here? Or are you proposing to leave nextind(s,i) and prevind(s,i) as-is?

[StefanKarpinski]

True, that's a good point, @stevengj. Maybe we should just leave this as is.