On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker <[email protected]> wrote: > > Hi Kevin, > > On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey <[email protected]> wrote: > > > Hello, > > > > FWIW, I'm excited at the prospect at seeing a new toolchain for > > Windows, since it would imply support for C++17 and so it would become > > easier for CRAN packages to depend on the newer C++ standard. > > > > One thing to keep in mind (having been the R installation owner in such a > place for multiple years) is that many coproprate or otherwise controlled > compute environments may not have access to a c++17 compiler on their > servers so making it easy for packages to rely on that is not purely > beneficial to all parts of the R community.
No, you're missing an important point here. On Windows, the toolchain version is tied to the version of R and we try to keep supporting at least one or two previous versions of R. So this means we always need to support the legacy toolchain for a while as well. Hence if we switch Windows to gcc-8 for R 4.0, we still rely on gcc-4.9 for continued support of R 3.3-3.6. This lag is what is making the maintenance of windows system libraries painful, and why we need to plan ahead. This is different from Linux where version of the compiler is given by the OS and not tied to the version of R. If we would miss the boat again, and R 4.0 on Windows would stick with gcc-49, this means we need to keep supporting gcc-49 as long as we want to support R-4.0, which is at least 2022 or 2023. This would be pretty bad. Even currently the latest versions of important system libraries used by R packages (e.g. the gdal stack) require recent compilers and cannot be built anymore with gcc-49. As more C++ projects are adopting C++14/17, we can no longer update these system libraries, missing out on all upstream fixes and advances. This would seriously decrement the quality of the R ecosystem. ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
