https://issues.apache.org/jira/browse/ARROW-12868

Do you think there's any way to define a str_locate function to match the behavior of stringr::str_locate using both the find_substring and utf8_length kernels?

I think the answer is no because this would require returning a struct column, and that's not possible? Is this limitation related to the issue in ARROW-13149 that @jonkeane was discussing recently?

On the struct column front, returning a struct column is totally fine right now (making a struct from R is a bit more complicated though).

However, right now more likely than not that struct will bet automatically turned in to a tibble (or at least that will be attempted) when pulling it into R. ARROW-13149 aims to make it so that structs will return as named lists instead of always being converted into tibbles automatically.

All of this is to say, I think it would be totally fine for this to a return a struct right now (so long as it doesn't return something super bad when attempting to be turned into a tibble) and so long as we are ok with the R side of what the results come out as (hopefully) changing soon

Cool, thanks @jonkeane.

IIUC, to achieve this we would need to use the project kernel, which takes ProjectOptions and isn't implemented in the R bindings yet. This seems be beyond the scope of what's reasonable to achieve in this PR. Should we create a separate Jira for that?

I created ARROW-13165 to follow up on the project kernel, with a comment in the Jira about using it to implement a binding for str_locate().

@jonkeane @ianmcook I agree with what you both say here, that all makes sense. So, is the plan to merge this as-is, and then look at creating bindings for str_locate once the other tickets are implemented?

So, is the plan to merge this as-is, and then look at creating bindings for str_locate once the other tickets are implemented?

Yes, if that sounds 👍 to you

Sounds like a plan!

Meanwhile it looks like ARROW-13157 has a PR, so if we wait a few days for that to get merged, then we can remove the skipped test in this PR before we merge it.

Meanwhile it looks like ARROW-13157 has a PR, so if we wait a few days for that to get merged, then we can remove the skipped test in this PR before we merge it.

Let's just do that then!

The PR for ARROW-13157 is merged, so I rebased and removed the skipped test. I'll merge when the CI is green.

I incorporated the find_substring_regex kernel added in ARROW-13157