Planning switch to C++17 after Boost 1.80

[mloskot]

Status

There is already a lot of changes and features happening in GIL for Boost 1.80.

I think, we're should to stick to C++11 or we are free to make baby step to C++14 because

1. We already prefer C++14 over C++11 as per discussions like
   • Fix any_image_view::const_t #526 (comment)
   • ci: Switch CI configuration to boostorg/boost-ci #642 (comment)
2. We have already dropped GCC 5 support (in 8b1c2d3)
3. We have already announced switch to C++14 in Boost 1.75 (in 8b1c2d3 too)

Plan: Boost 1.80

In Boost 1.80, let's do

1. Announce switch to ++14 in docs!: announce switch from C++11 to C++14 with Boost 1.80 #677
2. Announce plan to switch C++17 in next releases.
3. Create "C++ standard and compiler support" page in docs as per Glen's suggestion Add GIL release notes for Boost 1.75.0 website#562 (comment)

Plan: After Boost 1.80

After we announce the plan to switch to C++17, we will have more time to develop improvements that we have already discussed in various occasions:

• std::variant (refactor: Deprecate apply_operation in favor of variant2::visit for any_image #656 (comment))
• std::filesystem (Deprecate I/O interface using boost::filesystem::path #222)
• std::bind (std::bind2nd is removed in c++17 #126)
• std::allocate members (Most members of std::allocate are deprecated in C++17 #30)
• std::pmr::polymorphic_allocator (Add pmr image typedefs #529)
• Further improvements and simplifications to iterators (follow up to refactor: replace Boost.Iterator with Boost.STLInterfaces #669)

---

Unless there are no objections, I suggest we follow the plan above.

[striezel]

While the accouncement "We may also change the required minimum C++ version from C++11 to C++14." in Boost 1.75 certainly gives the option to switch to C++14 with the release of Boost 1.80, there are still several CI builds (Clang and GCC) that run in C++11-mode and compile and pass the tests just fine with C++11. So there is no urgent need to move to C++14, but I can certainly understand the desire to move to a newer standard.

That being said: Is there any data on how many users of Boost still use compilers that support C++11 but not C++14? It would be nice to know and possibly make it easier to decide if C++11 support can be dropped.

[mloskot]

certainly gives the option to switch to C++14 with the release of Boost 1.80

Yes, that was the plan to have an open option.

there are still several CI builds (Clang and GCC) that run in C++11-mode and compile and pass the tests just fine with C++11

Yes, that is fine. Switch does not happen overnight.
Having an open option to start the switch we can initially keep all the passing builds, if we want, and eliminate them as we progress with refactoring and introduction of features that require newer C++ version.

Is there any data on how many users of Boost still use compilers that support C++11 but not C++14?

I am not aware of any data, but I have read all the (fairly recent) discussions on the Boost mailing lists, especially the lengthy thread "Future of C++ and Boost" here and here. The sentiment seems to be like this (warning: quoting out of wider context):

• Personally, there's little in C++14 that makes that move attractive for me. C++17 yes (for if constexpr).
• If there are people who cannot use C++11 for some reason, they can
  use older boost releases.
• Policy recommended by Peter Dimov is considered as a sensible https://pdimov.github.io/articles/phasing_out_cxx03.html

My own impression is that people seem to be either using either ancient C++ version or have already jumped to C++17.

We could jump to C++17, but since we have already announced desire to move to C++14, then it is sensible, IMHO, to take a baby step. (I am looking forward to the iterators overhaul with Boost.STLInterfaces which requires C++14).

BTW, w.r.t. data, I happen to mainain a little ODBC wrapper C++14 library that has ~250 stars and is used by r-odbc - I mean, there seem to be some user base. I asked on GitHub/Twitter about C++ version the users use with nanodbc and 3 responses arrived :-) but all for C++17 - - nanodbc/nanodbc#321

[striezel]

Policy recommended by Peter Dimov is considered as a sensible https://pdimov.github.io/articles/phasing_out_cxx03.html

That policy even suggests to wait two releases after the deprecation announcement, not just one. But Boost 1.75 was more than two releases ago, so it should be no problem to switch to C++14, at least as far as the policy is concerned. Since stuff still compiles with C++11 compilers, that announcement alone should not hurt anybody, but it gives us the possibility to move on to a newer standard.

PS:

Plan: Boost 1.80

In Boost 1.80, let's do

1. Announce switch to ++14

Just opened a PR for that announcement: #677

[mloskot]

That policy even suggests to wait two releases after the deprecation announcement, not just one.

Yes, for C++14 that requirement is fulfilled and we will wait with C++17 for at least two releases, counting from 1.80.0

[mloskot]

I have just proposed announcement in the release notes about our plan to require C++17 in PR #694

Once we complete the switch, this will turn into BREAKING change in the release notes for future Boost release.