On Thu, Feb 23, 2023 at 9:28 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:

To ensure I'm understanding correctly, this means that a core library everybody else depends upon could declare it is dropping support for C++ 17 as that is old, and thereafter all dependent libraries by definition would require C++ 20 as a minimum?

Correct. The "everybody else" would be given notice two Boost releases (6 months) in advance to fork what they want into their own libraries to maintain compatibility with older standards. Glen

On Thu, Feb 23, 2023 at 10:06 AM Niall Douglas wrote:

I assume if a core library announces it intends to go past C++ 11 in the next year if enough people complain here its maintainer could be persuaded to hold off until the end of 2023?

Anyone is free to try and persuade any maintainer to maintain compatibility with C++11 or any old language standard. You're also free to help any affected library maintainers support any old language standards by volunteering your time with pull requests. Glen

On 23/02/2023 15:44, Dominique Devienne wrote:

On Thu, Feb 23, 2023 at 4:05 PM Niall Douglas via Boost mailto:boost@lists.boost.org> wrote:

RHEL 7 EOLs in June 2024 and it comes with GCC 4.8.

But you can use official RHEL DTS packages which provide newer compilers too. Which is exactlty what is happening where I work. So even w/o going as far as compiling your own GCC from source, you can (relatively) easily use much newer GCC, in our case 9.1.1 from DTS9 on RHEL7 with C++17. Why be limited to the default system compiler?

It's not us, it's our customers. And no, they won't use any compiler which isn't the system default. Thus we all await with relish and excitement when RHEL 7 goes EOL, and we can finally wave goodbye to all GCCs before 8. Niall

On Thu, Feb 23, 2023 at 11:27 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:

No, core library maintainers can't just go ahead and make their libraries C++20. They wouldn't be core library maintainers if they did things like that.

Either Boost library authors who depend on others can reach those agreements via discussions on the list, or they can't. I believe they will act sensibly without enforcement. i.e. Whatever the permissions on paper, I doubt core library maintainers would drop C++14 or C++17 any time soon. I know I won't. In any case the release managers are not going to impose a minimum language standard on those libraries. Glen

On 2/23/23 19:27, Peter Dimov via Boost wrote:

No, core library maintainers can't just go ahead and make their libraries C++20. They wouldn't be core library maintainers if they did things like that.

The moral... obligation (I'm not sure this is the right word) to your users to continue supporting the old C++ standards remains the same regardless of what we do or don't announce Boost-wide. Even if the release managers decided to announce that the next Boost release no longer supports C++03, I would still be reluctant to remove said support from my libraries, as long as I know there are C++03 users. That is until I'm no longer willing to support it, at which point, again, it doesn't matter what release managers say. For this reason I find proposals like this pretty much moot, sorry.