I have no opinion about the benefits of upgrading to C++17. From the R perspective, there are a handful of packages on CRAN that require C++14 or C++17. Last year, when I asked other R package maintainers why they hadn't upgraded to newer C++ standards, the reasoning was that because many packages try to support the 5 last versions of R, the Windows 3.6 issue is still limiting, at least if you hope to be a package that others depend on. But I don't think this is an argument to prevent us from upgrading: R package developers have been more likely to take on `arrow` as an optional dependency, if at all, given the size/complexity of the build.
Here's a tactical suggestion: for 10.0, we could upgrade all* of our packaging and CI jobs to build with C++17, but not add code that cannot compile on C++11 (hence the *, we will need to maintain at least one C++11 CI job to assure that). Then, assuming there are no adverse consequences, we can start upgrading the codebase to C++17, and 11.0 would be the first release that can't build on C++11. Neal On Wed, Aug 17, 2022 at 3:56 AM Antoine Pitrou <anto...@python.org> wrote: > > Le 17/08/2022 à 10:48, Jacob Wujciak a écrit : > > 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 > > Well, I can't say for sure, but according to this StackOverflow post it > would probably be ok: > https://stackoverflow.com/a/54030282 > > Do we have CI for that macOS platform? > Do you know which XCode version that Apple LLVM version corresponds to? > >
