GH-50713: [C++] Replace return_type and enable_if_return with <type_traits> helpers

[taepper]

Rationale for this change

This is the first part of simplifying functional helpers which are no longer required since the code-base supports more recent C++ versions. (See #50713 and #50250)

What changes are included in this PR?

This removes the return_type related helpers from functional.h. Also, the unused helpers is_overloaded, enable_if_empty and enable_if_not_empty are removed.

Are these changes tested?

Yes

Are there any user-facing changes?

No

• GitHub Issue: [C++] Replace return_type helpers from util/functional.h #50713

[github-actions]

Thanks for opening a pull request!

This pull request has been automatically converted to a draft because its title doesn't match Arrow's required format.

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

After updating the title, you can mark the pull request as ready for review.

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[taepper]

@pitrou For this case:

template <typename Type, typename ConsumeValue, typename ConsumeNull>
requires std::is_void_v<
std::invoke_result_t<ConsumeValue, uint32_t, typename GetViewType<Type>::T>>
voidVisitGroupedValues(const ExecSpan& batch, ConsumeValue&& valid_func,
ConsumeNull&& null_func) {

I used typename GetViewType<Type>::T to e.g. map from Int32Type to int32_t / Decimal128Type to Decimal128. Is this the idiomatic way (we are not using a View here)? I see that also UnboxScalar<Type>::T might be possible?

[pitrou]

Yes, this seems ok to me.

[pitrou]

@github-actions crossbow submit -g cpp

[HuaHuaY]

I think we may be able to use std::is_invocable_r_v here. It might also work for cases where the return type is void. It depends on how strict we want the constraints to be.

[HuaHuaY]

And FYI, C++20 provides std::same_as to replace std::is_same_v.

[taepper]

And FYI, C++20 provides std::same_as to replace std::is_same_v.

Ah, nice! I added #50720 for this change, as this is not widely used in the code-base for now.

I think we may be able to use std::is_invocable_r_v here. It might also work for cases where the return type is void. It depends on how strict we want the constraints to be.

I am not sure whether I find the std::is_invocable_r_v more readable in this codebase, compared to using more well-known constructs?

[HuaHuaY]

The role of Enable is to trigger SFINAE, so we could replace it with requires.

[taepper]

This is a very good point, I fixed this locally:

commit f07ffc993ea0337052490b5fedc8d5ea4c601b5a (HEAD -> minimize-functional-metaprogramming)
Author: Alexander Taepper <alexander.taepper@gmail.com>
Date: Wed Jul 29 19:05:30 2026 +0200
replace another `typename Enable` with `requires`
diff --git a/cpp/src/arrow/util/iterator.h b/cpp/src/arrow/util/iterator.h
index 3a098b1455..aaf6531dfe 100644
--- a/cpp/src/arrow/util/iterator.h+++ b/cpp/src/arrow/util/iterator.h@@ -519,9 +519,8 @@ struct FilterIterator {
/// \brief Like MapIterator, but where the function can fail or reject elements.
template <typename Fn, typename From,
typename Ret = typename std::invoke_result_t<Fn&, From>::ValueType,
- typename To = std::tuple_element_t<0, Ret>,- typename Enable = std::enable_if_t<- std::is_same_v<std::tuple_element_t<1, Ret>, FilterIterator::Action>>>+ typename To = std::tuple_element_t<0, Ret>>+ requires std::is_same_v<std::tuple_element_t<1, Ret>, FilterIterator::Action>
Iterator<To> MakeFilterIterator(Fn filter, Iterator<From> it) {
return Iterator<To>(
FilterIterator::Impl<Fn, From, To>(std::move(filter), std::move(it)));

Is it okay to push these changes @pitrou ? I can also do this in the second part of #50250 instead.

[pitrou]

Is it okay to push these changes @pitrou ?

Yes, please do.

[HuaHuaY]

Thank you for this PR. I've left two comments. We can consider whether to incorporate them in the future PRs. To be honest, I’m not sure how much syntax our CI can handle.

[pitrou]

The failing C++ builds above are unrelated, FTR.

[pitrou]

+1, I'll wait for the CI builds

[taepper]

I guess I should rebase onto main given the CI failures mentioning simdjson which should have been fixed in #50732

[pitrou]

@github-actions crossbow submit -g cpp

[pitrou]

I'll wait for the latest CI results and then merge :)

[github-actions]

Revision: 42bbe09

Submitted crossbow builds: ursacomputing/crossbow @ actions-e1b94b023a

Task	Status
example-cpp-minimal-build-static
example-cpp-minimal-build-static-system-dependency
example-cpp-tutorial
test-build-cpp-fuzz
test-conda-cpp
test-conda-cpp-valgrind
test-debian-13-cpp-amd64
test-debian-13-cpp-i386
test-debian-experimental-cpp-gcc-15
test-fedora-42-cpp
test-ubuntu-22.04-cpp
test-ubuntu-22.04-cpp-bundled
test-ubuntu-22.04-cpp-emscripten
test-ubuntu-22.04-cpp-no-threading
test-ubuntu-24.04-cpp
test-ubuntu-24.04-cpp-bundled-offline
test-ubuntu-24.04-cpp-gcc-13-bundled
test-ubuntu-24.04-cpp-gcc-14
test-ubuntu-24.04-cpp-minimal-with-formats
test-ubuntu-24.04-cpp-thread-sanitizer

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 5d6cb93.

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 2 possible false positives for unstable benchmarks that are known to sometimes produce them.