Hello,
We are in 2022 and Arrow C++ still strives to be compatible with C++11.
Maintaining compatibility has caused us growing pains since third-party
libraries have begun requiring C++14 or later. Boost is warning that it
will soon require C++14
(https://issues.apache.org/jira/browse/ARROW-17406). The Abseil C++
library, an indirect dependency of the GCS filesystem implementation,
requires C++14. Other Google libraries such as GTest and Protocol
Buffers are following suit and starting to require C++14 (see
https://github.com/protocolbuffers/protobuf/commit/500cbd7b90fa7eb5716a3bbc6aa788ada028a1bf).
Moreover, C++11 has a set of limitations which causes quality of life
issues in daily development. While C++14 wouldn't improve things much,
being able to use C++17 features would be a large boost in
maintainability and ease of development. This is demonstrated by a draft
PR submitted one year ago (https://github.com/apache/arrow/pull/10414).
The requirement for C++11 compatibility was driven by packaging concerns
due to old gcc versions being used in a couple contexts:
1) On old (but supported) Red Hat-like systems such as CentOS 7, the
system gcc only supports C++11 (typically, gcc 4.8 on CentOS 7).
However, one can install a Developer Toolset package to get a more
modern development enviroment on such a system, that can produce
binaries fully compatible with the base system libraries (see e.g.
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/,
https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/8/html/8.0_release_notes/dts8.0_release).
2) Building R packages for Windows and R < 4.0 uses an old toolchain
based on gcc 4.9, which only supports C++11. However, building packages
for R >= 4.0 uses a more recent toolchain based on gcc 8.3, supporting
C++17. It is reasonable to drop support for R < 4.0 on Windows, as
suggested in this JIRA comment:
https://issues.apache.org/jira/browse/ARROW-17110?focusedCommentId=17571472&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17571472
All in all, I'm proposing that we move away from C++11 to a more recent
version. Furthermore, I'm proposing that we move to C++17, as it
provides considerable quality of life improvements and is more
forward-looking than basing ourselves on C++14.
I do not expect significant pushback on this proposal, but if you have
good reasons to oppose this move, please say so quickly. Otherwise, a
formal vote will be launched soon.
Regards
Antoine.
