I am generally in favour of this proposal but would like to mention that we have to be able to build on MacOS 10.13 for the R package due to CRAN using it. The CRAN builder comes with: Apple LLVM version 10.0.0 (clang-1000.10.44.4); GNU Fortran (GCC) 8.2.0
Antoine Pitrou <anto...@python.org> schrieb am Mi., 17. Aug. 2022, 10:21: > > 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. >
