Moving to C++14

[rok-cesnovar]

This is a step towards closing #1300 (moving up to C++17) that we can do immediately after the release.

The immediate consequence of moving up to C++14 (we currently support a subset - C++1y) is that the minimum required g++ would become g++ 5 as opposed to 4.9.3. There is no change for clang (clang does not have official support for C++1y) and the clang version supporting C++14 is Clang 3.4 which is the same one we listed as minimum now.

There are major changes that would be caused by that:

• On Windows, RTools 3.5 would no longer be supported and thus all upstream Stan R packages that will use Stan 2.28+ would no longer support R3.X.

  R 4.1 is now in the RC phase and once its released (any day now) CRAN will no longer test packages with R3.X. CRAN tests with the current and old release (which is now 3.6.X). Once R-release becomes 4.1, R-old will become 4.0.x so using R 4.X should be recommended in all those upstream packages anyway.

• cluster users would need to upgrade to g++ 5.

  Clusters are the only other larger group of users that would be affected. Non-cluster Linux distros come with g++5 or higher for quite a few years now and Mac users are not affected.

The main reason of why I think the major changes are OK is that users that will not want to upgrade to g++ 5 will be able to stay with 2.27 which should cover them for quite some time (given that a majority of users still use Stan 2.21 we should be good on that front for awhile once we get to 2.27).

The only question I have on this is does this requires a bump of the major version of Stan? I am leaning towards no but I am not sure.

cc: @syclik @bob-carpenter @bbbales2 @t4c1 @SteveBronder @wds15 @andrjohns @yizhang-yiz et al

[wds15]

I don't think this would need to bump in major version numbers.

As you say, it's a tough call for cluster users who will have to deal with it in some way.

[SteveBronder]

I wonder if for R we could make a fixed version of stanheaders and rstan like StanHeaders227 and rstan227, then users who need C++1y can use that while we then bump up to C++14 for rstan and StanHeaders

[rok-cesnovar]

R 4.1 has officially been released.

I am going to bring this up on next weeks meeting and then make a discourse thread to gather more feedback.

@SteveBronder AFAIU R will download the last suitable package that works with that version.

[andrjohns]

I'm going to throw my hat in the ring and say that's probably a little early for this change. R3.x is still used as the 'stable' default version to install in a lot of workplaces (including mine), and (as of a few months ago) is the version pre-installed with the AWS Amazon Linux image, so we'll likely end up fragmenting a pretty significant portion of the userbase.

Plus, once 2.27 manages to clear CRAN hurdles, RStan will have feature-parity with the main stan version for the first time in a while. It might be a bit of a tough sell for some users to then fall behind again pretty soon after.

[rok-cesnovar]

Thanks @andrjohns, that is definitely a valid point and concern.

This would only affect RTools 3.5 on Windows and those with g++ 4.9.3 on Linux.

So the only change would be that Windows R3.x users would not have access to binaries for newer Rstan versions. Linux users install from source anyways and would only be affected in that they would have to install g++ 5 if currently using 4.9.3. Mac users would most likely not be affected (worst case they would have to install from source).

[WardBrian]

We bumped to C++17 in #3110