ARROW-10959: [C++] Add scalar string join kernel

[maartenbreddels]

@jorisvandenbossche I've implemented this kernel as a binary (arity) kernel, so the input list array and the separator input string array can both be an array (see python test).

I did not implement the case where the input list is a scalar, and the separator an array, since I don't think that's very common.

And note that the kernel is named binary_join because it takes string-like and binary-like inputs.

[github-actions]

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

[maartenbreddels]

Failures seem unrelated.
@pitrou this is ready for review assuming @jorisvandenbossche agrees with the current behavior

[pitrou]

Thanks @maartenbreddels . Here are some comments.

[ianmcook]

Regarding "join" in the name:
+1 for consistency with Python's join function
-1 because as Arrow gains more database-like features, the word "join" is likely to confuse people. "concat" might be better.

Regarding "binary" in the name:
IMO that is likely to cause users to get the impression that this is not for strings.

It would also be good for the name to reflect that this operates on a list array.

How about renaming it list_concat?

[westonpace]

I'll just point out that "join" is not a python-ism. There is a string join in Java, Rust, C#, JavaScript, etc. and it is consistently called join. I think R is the only language I can find that doesn't call it "join".

[ianmcook]

I'll just point out that "join" is not a python-ism. There is a string join in Java, Rust, C#, JavaScript, etc. and it is consistently called join. I think R is the only language I can find that doesn't call it "join".

SQL—which probably has more users than all those languages combined 😁

[ianmcook]

I'll just point out that "join" is not a python-ism. There is a string join in Java, Rust, C#, JavaScript, etc. and it is consistently called join. I think R is the only language I can find that doesn't call it "join".

SQL—which probably has more users than all those languages combined 😁

Snark aside, that's a good point, and since users who are thinking in the SQL way will always be at least one abstraction layer removed from the C++ library, that makes me think "join" is fine 👍

[jorisvandenbossche]

In SQL it's called CONCAT? (https://www.w3schools.com/sql/func_mysql_concat.asp, although this doesn't have the concept of a join separator)

[ianmcook]

In SQL it's called CONCAT? (https://www.w3schools.com/sql/func_mysql_concat.asp, although this doesn't have the concept of a join separator)

In SQL, concat_ws is the variant with a separator

[pitrou]

@maartenbreddels Do you want to update this PR?

[pitrou]

I'm going to take this up.

[pitrou]

I adressed review comments, added a benchmark, and made binary_join 3x faster (in particular by preallocating data at the right size).

[pitrou]

Still a TODO to address (also support large_list inputs).

Edit: done

[bkietz]

To keep the public overloads to a minimum, these should probably just take Datums. Added https://issues.apache.org/jira/browse/ARROW-12953

[bkietz]

We don't lose anything for string kernels which always do their own allocation, but it's worth noting that *out is always a correctly shaped ArrayData. We could also safely write

Suggested change

	std::shared_ptr<Array> string_array;
	RETURN_NOT_OK(builder->Finish(&string_array));
	*out = *string_array->data();
	RETURN_NOT_OK(builder->FinishInternal(const_cast<std::shared_ptr<ArrayData>*>(&out->array())));