[C++] Ensure compatibility between std::span and arrow::util::span

[pitrou]

Describe the enhancement requested

It would be nice to ensure compatibility between std::span and our own implementation arrow::util::span, if the former is present (which can be detected using feature testing -- see __cpp_lib_span).

Then we'll be able to use span more widely in our public APIs.

Component(s)

C++

[pitrou]

cc @benibus @bkietz

[ShaiviAgarwal2]

@pitrou
To ensure compatibility between std::span and arrow::util::span, we need to modify the arrow::util::span class to meet the requirements of std::span. This can be done by adding the necessary member functions and type aliases to arrow::util::span. We also need to specialize the std::ranges::enable_borrowed_range template for arrow::util::span to indicate that it is a borrowed range. Finally, we need to add feature detection to check if std::span is available and use it if it is, falling back to arrow::util::span otherwise.

Here's the plan in pseudocode:

1. Check if __cpp_lib_span is defined to determine if std::span is available.
2. If std::span is available, define arrow::util::span as an alias for std::span.
3. If std::span is not available, define arrow::util::span as a separate class that meets the requirements of std::span.
4. Add the necessary member functions and type aliases to arrow::util::span to meet the requirements of std::span.
5. Specialize the std::ranges::enable_borrowed_range template for arrow::util::span to indicate that it is a borrowed range.

[felipecrv]

@ShaiviAgarwal2 is this a ChatGPT-generated answer?

[Divyansh200102]

Hi @pitrou I would like to work on this ,since I am a beginner can you please explain the steps involved in ensuring the compatibility between std::span and arrow::util::span or any documentations I need to refer to?

[pitrou]

@Divyansh200102 When you say you are a beginner, is that that you are a Arrow beginner or a C++ beginner?
If you are a C++ beginner, then I don't think tackling this issue is a good idea.

[Divyansh200102]

@Divyansh200102 When you say you are a beginner, is that that you are a Arrow beginner or a C++ beginner? If you are a C++ beginner, then I don't think tackling this issue is a good idea.

I am not a c++ beginner @pitrou I know the basics ,I am arrow beginner and I want just to want to know specifically for this issue what i need to do.

[pitrou]

I am not a c++ beginner @pitrou I know the basics ,I am arrow beginner and I want just to want to know specifically for this issue what i need to do.

std::span appears in C++20, but the Arrow C++ codebase is compatible with C++17. Therefore, we implemented a homegrown backport arrow::util::span.

However, some users may use Arrow C++ with C++20 codebases that also use std::span. For such users, the fact that std::span and arrow::util::span are independent classes may lead to pointless boilerplate.

What we would need here is some functionality to make arrow::util::span compatible with std::span at least when C++20 is enabled. This implies:

1. implicit conversion from arrow::util::span to std::span
2. implicit conversion from std::span to arrow::util::span
3. (in)equality operators between arrow::util::span and std::span

I might forget something but the above list is a good start (@bkietz ?).

[bkietz]

What we would need here is some functionality to make arrow::util::span compatible with std::span

I think a better approach would be an #if which aliases std::span to arrow::util::span if possible, falling back to the backport otherwise. We don't have a CI job which compiles with c++20 but there is a crossbow task which should pass if the two are compatible.

If greater rigor is desired, expanding span_test.cc should suffice since that will be run against std::span on the crossbow job and against the backport otherwise. It would probably also be good to expand the number of jobs we're running at c++20; I'd be surprised by not shocked if at least one STL's std::span implementation differed in some annoying way.

[pitrou]

I think a better approach would be an #if which aliases std::span to arrow::util::span if possible, falling back to the backport otherwise.

Could that affect ABI compatibility if e.g. Arrow C++ is built with C++17 but used in a C++20 context or vice-versa? Changing a class implementation based on user compile flags is fragile...

We don't have a CI job which compiles with c++20

We could perhaps switch one of the existing C++ jobs on GHA to C++20.

[bkietz]

ABI compatibility if e.g. Arrow C++ is built with C++17 but used in a C++20

That would indeed break in the approach I described. If we want that to work, we would need the implicit conversions you described. Some of the conversions might already be handled by the generic contiguous range constructors, though.

[pitrou]

Yes, we want binary Arrow C++ artifacts (i.e. libraries) to be usable regardless of third-party compiler options.
(same as with NDEBUG)