Confirmed this expands to the original logic, for both StringView (here) and StringArrays (above), to match on an array of regex. Why the use of macros?

Same pattern, and same question as before.
It's the same logic (for a single regex) into a macro to use for both StringView and StringArray. Why the macro?

@wiedld Thanks so much for reviewing ❤️

Confirmed this expands to the original logic, for both StringView (here) and StringArrays (above), to match on an array of regex. Why the use of macros?

It's the same logic (for a single regex) into a macro to use for both StringView and StringArray. Why the macro?

I just want to reduce duplicate code here. I remember that I have struggled when I implement generic functions instead of macro. But if it makes code hard to read/debug/maintain I can try to remove the macro and using another solution.

I played around a bit, and It looks like some of the common array builder methods are not traits on ArrayBuilder. Specifically, I got to here and was blocked by the builder.append_value():

fn process_regexp_match<'a, T: ?Sized, A: ArrayAccessor<Item = &'a str>, O: OffsetSizeTrait, B: ArrayBuilder>(
    array: ArrayIter<A>,
    regex: &Regex,
    list_builder: &mut GenericListBuilder<O, B>,
) -> Result<(), ArrowError> {
    ...
}

It looks like this method is only implemented on 9 of the 15 current ArrayBuilder implementations. Not sure on whether the method should be pulled into the interface or whether we want additional builder traits/interface definitions (maybe in a separate PR). @alamb ?

Otherwise, yes the macro is the alternative for DRY. But it feels like we want abstraction (a.k.a. a trait).

A trait sounds like a good idea to me, but unless we have a specific idea/proposal of one, I think macros are the best way to proceed (we can always clean the code up later)

Or perhaps @wiedld if you have time you can try and work out what a trait based solution would look like so we can compare

I can do that in a follow up PR. Thank you for the input @alamb .

@tlm365 -- if the additional test gets added, then I can approve.

@alamb @tlm365 -- Here is a proposed trait ValuesBuilder: ArrayBuilder for common interfaces in building a list of values.

Note that there were several other common sets of builder functionality (such as building lists of lists), but I didn't address that due to (a) keep the PR small, and (b) I knew only of this immediate use case (altho there are likely others).

Much nicer not having this anymore.

There is no difference in the match results with, or without, flags. Might be nice to have test cases demonstrating this difference. 🙏🏼