+1. I'm very much in favor of upgrading to C++17. I am lucky to often get to work with people that are new to the Arrow C++ code base and a common feedback is that the code is quite complex. While I do not think moving to C++17 will solve this problem by itself I'm pretty confident that being able to remove SFINAE (if constexpr), remove some of our backports (optional, string_view), and move into lambda captures would all help reduce this complexity.
In addition to allowing engineers like myself to better understand the code base it would also, I think, be a small boost in helping to attract talented C++ developers into working on the code base. Being forced to reinvent or workaround features that have been efficiently solved in a newer version of the language is a discouraging experience. Finally, I have been interviewing C++ engineers as a part of my job and I think we have reached a point where the average interviewee has been working on a C++17 code base. They either won't have experience with C++11 or will view it as a step backwards. This is somewhat backed up by quantitative data such as JetBrains surveys[1][2] which reports that C++11 usage has gone from 61% in 2019 to 40% in 2021 (with 50% of C++11 respondents stating they plan to migrate to a newer version in the next year). In summary I think the change is important to recruit, and keep the interest of, talented C++ developers. [1] https://www.jetbrains.com/lp/devecosystem-2019/cpp/ [2] https://www.jetbrains.com/lp/devecosystem-2021/cpp/ On Wed, Aug 17, 2022 at 4:23 AM Matthew Topol <m...@voltrondata.com.invalid> wrote: > > I can definitely vouch for the benefits of upgrading to C++17, it makes > general development significantly more enjoyable! > > On that end, I second Neal's suggestion for deployment, that's roughly > the same plan we used in my past experience when performing a compiler > upgrade on a very large codebase. > > --Matt > > On Wed, Aug 17 2022 at 08:45:34 AM -0500, Neal Richardson > <neal.p.richard...@gmail.com> wrote: > > 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 > > <mailto: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? > >> > >> >
