Repository navigation
[C++] Ensure compatibility between std::span and arrow::util::span #36612
Description
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++
Activity
pitrou commentedon Jul 11, 2023
cc @benibus @bkietz
ShaiviAgarwal2 commentedon Nov 15, 2023
felipecrv commentedon Nov 15, 2023
@ShaiviAgarwal2 is this a ChatGPT-generated answer?
Divyansh200102 commentedon Dec 2, 2023
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 commentedon Dec 2, 2023
@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 commentedon Dec 3, 2023
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 commentedon Dec 4, 2023
std::spanappears in C++20, but the Arrow C++ codebase is compatible with C++17. Therefore, we implemented a homegrown backportarrow::util::span.However, some users may use Arrow C++ with C++20 codebases that also use
std::span. For such users, the fact thatstd::spanandarrow::util::spanare independent classes may lead to pointless boilerplate.What we would need here is some functionality to make
arrow::util::spancompatible withstd::spanat least when C++20 is enabled. This implies:arrow::util::spantostd::spanstd::spantoarrow::util::spanarrow::util::spanandstd::spanI might forget something but the above list is a good start (@bkietz ?).
bkietz commentedon Dec 4, 2023
I think a better approach would be an
#ifwhich aliasesstd::spantoarrow::util::spanif 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.ccshould 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 commentedon Dec 4, 2023
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 could perhaps switch one of the existing C++ jobs on GHA to C++20.
bkietz commentedon Dec 4, 2023
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 commentedon Dec 4, 2023
Yes, we want binary Arrow C++ artifacts (i.e. libraries) to be usable regardless of third-party compiler options.
(same as with
NDEBUG)82Kang commentedon Mar 18, 2026
@pitrou Hi, Can I pick this one up if this is still relevant? I am new to Arrow but my initial assessment is that the devs are still reaching for
arrow::util::span. Also would love to know your opinion on how we should we address this, should we go in the direction of migrating callers over time OR change thearrow::util::spanto simply be a wrapper on thestd::spanto start with? Thanks!pitrou commentedon Mar 18, 2026
@82Kang Thanks for proposing to do this! However, this is issue is actually obsoleted by #48588, for which there is already a PR open.
But please feel free to look at other open issues, especially the "good first issue" ones!