Sorry for a "one more thing email" but I had one more thought regarding R 3.6 support for Windows. I think those users should continue to be able to use Arrow 10.0.0. So this would only be an issue if we detected a critical bug in 10.0.0 (which we could backport if it was bad enough) or if they wanted to use newer features (which could be an incentive to upgrade their R version).
On Wed, Aug 17, 2022 at 4:30 AM Weston Pace <weston.p...@gmail.com> wrote: > > +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? > > >> > > >> > >
