ARROW-1487: [C++] Implement casts from List<A> to List<B>, where a cast function is defined from any A to B

[Licht-T]

This closes ARROW-1487.

[wesm]

There's a couple issues with this:

a) We should not perform any additional copying or allocation beyond what is required to perform the cast on the child, i.e. we should simply reuse the buffers from the input array without copying

b) It would be better to resolve the cast kernel for the child data when the kernel is resolved in GetCastFunction. Instead of defining a functor for list, instead create an alternative implementation of UnaryKernel that has the child cast kernel as a member variable. This is what I meant in https://issues.apache.org/jira/browse/ARROW-1487 by "If a cast rule for the child type is not implemented, the failure should occur during kernel selection rather than at kernel evaluation time."

[wesm]

In here, per below, we will want to verify that the casted result retains zero-copy references to the buffers from the parent array.

There is another nuance to be aware of, which is that the offset member may be non-zero, so in that case simply reusing the buffers is not the appropriate action

[Licht-T]

@wesm Thanks for your review! Now revised the implementation (but the test codes is not yet). Is this the right direction?

[wesm]

I'm sort of thinking of having a ListCastKernel : public UnaryKernel implementation. Would you mind if I took a pass at working on this?

[Licht-T]

@wesm IMO, we don't have to create the special case like ListCastKernel. I think simply checking child Field is sufficient.

[wesm]

You can take a look at what I just did -- for the moment casting sliced ListArray raises an exception, we'll need to do some more work to make that work

[wesm]

I think we can generalize to support struct casts and have instead a NestedCastKernel when the time comes. I think we should defer that a bit until we've dealt with the sliced list case. The problem with the current CastKernel is that it's tied up in the business of memory allocation for primitive arrays. We'll keep needing to do some refactoring around this as we implement more kernels which are capable of writing into pre-allocated memory

[wesm]

macOS build stalled out due to ARROW-1880

[Licht-T]

Thnaks @wesm! I understand why normal CastKernel and ListCastKernel are needed separately.