On 8/25/2018 11:07 PM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Sunday, August 26, 2018 3:17 AM

On 8/25/18 12:51 PM, Mike Dev via Boost wrote:

...

From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in ac++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_ g)

...

When can we drop C++03 support? :D

My understanding has been the boost only requires that libraries be conforming to the current C++ standard. I don't think that requires for support for C++03

I certainly didn't want to claim otherwise as a lot of libraries already require c++11 or later. However, I'm talking about dropping c++03 support in libraries that did support it till now.

Considering the strong internal coupling between older boost libraries, an individual library can't drop c++03 support without this decision affecting many, many other boost libraries. And while external users that can't migrate to c++11 have the option to just stick to an older boost version, internal users (aka other boost libraries depending on it) can't do that. So, let's say the maintainer of Boost.iterator wants to drop c++03 support and start using c++11 features. That would mean that at least a dozen or so other libraries that depend on it would suddenly also no longer be c++03 compatible without them having any say in it. If I were a boost library maintainer I'd certain not want to make the switch to c++11 under those conditions, even if I'd do it with a standalone library for which I can just release a new major version. This is, why I think, such a decision needs to be made by all affected maintainers (or at least by most of them) together.

You have things backward. How can all maintainers decide what level of C++ support a particular library should have ? Library X has features which determine what level of C++ support it needs. Simply because dependent libraries A, B, and C use library X they certainly can not decide for library X what level of C++ support it should have ? I think you do not seem to understand that a library's level of C++ support depends on the C++ language and library idioms it uses, not on some theoretical need to support some level of the C++ standard. If a library works at the C++03 level and Boost decides to "drop C++03 support" in your terms, what do you actually propose to do with such a library ? I would really like to know your answer to that ? Are you going to force it to use some C++11 on up feature in its code so that it no longer compiles at the C++03 level, even when it has no use for any C++11 on up feature anywhere in its implementation ? I am sure you realize how silly that would be. Are you going to drop the library from the list of Boost libraries even though the library works perfectly well with users who compile it with C++11, C++17, or C++20 levels ? That would really be absurd. Do you want to make an announcement on the Boost web page that Boost libraries which support C++03 may not support that level in the future and therefore Boost end-users are encouraged to use a higher level of C++ when using Boost libraries ? That might be reasonable, but then again we can say that for any library, ie. that it might only work in the future with a higher level of the C++ standard than it currently supports. So now can you see why your suggestion of Boost "dropping support for C++03", like others in the past who have said the same thing, is so generally meaningless ? It is because practically there is nothing to be done except perhaps a general announcement on the Boost web page, and even that has no affect on libraries which support C++03 right now, nor should it.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 26 August 2018 14:02 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] A possible date for dropping c++03 support

Edward Diener wrote:

...

Are you going to force it to use some C++11 on up feature in its code so that it no longer compiles at the C++03 level, even when it has no use for any C++11 on up feature anywhere in its implementation ?

He wasn't suggesting anything like that. His point is simply that if a library is heavily depended upon, the author's decision to drop C++03 support affects all downstream libraries, which by virtue of having this dependency will also lose C++03 support even if they themselves use no non-C++03 features.

Consequently, said author would be reluctant to break C++03 compatibility because it would affect more than just one library.

Do we have any idea how many real examples of this dependency there are?

But if we officially "drop C++03 support" he'll be freer to do so.

And feel less obliged to try to provide a 'workaround' where possible #ifdef C++03 do something old-school #else do something trendier #endif and instead saying #ifdef C++03 #error " C++03 not supported!" Can we make may those who wish to 'Officially' drop support for C++03 feel better (and quiet the repeated requests) by Officially Deprecating use of C++03 compilers and use of -std=c++03 (and next year deprecating C++11 ;-) Paul

On 8/26/2018 9:02 AM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

Are you going to force it to use some C++11 on up feature in its code so that it no longer compiles at the C++03 level, even when it has no use for any C++11 on up feature anywhere in its implementation ?

He wasn't suggesting anything like that. His point is simply that if a library is heavily depended upon, the author's decision to drop C++03 support affects all downstream libraries, which by virtue of having this dependency will also lose C++03 support even if they themselves use no non-C++03 features.

Consequently, said author would be reluctant to break C++03 compatibility because it would affect more than just one library.

But if we officially "drop C++03 support" he'll be freer to do so.

Only if "drop C++03 support" actually means something on a practical level rather than just verbiage.

On 8/26/2018 12:23 PM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Sunday, August 26, 2018 8:51 PM

On 8/25/2018 11:07 PM, Mike Dev via Boost wrote:

...

...

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Sunday, August 26, 2018 3:17 AM

On 8/25/18 12:51 PM, Mike Dev via Boost wrote:

...

From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in ac++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_ g)

...

When can we drop C++03 support? :D

My understanding has been the boost only requires that libraries be conforming to the current C++ standard. I don't think that requires for support for C++03

I certainly didn't want to claim otherwise as a lot of libraries already require c++11 or later. However, I'm talking about dropping c++03 support in libraries that did support it till now.

Considering the strong internal coupling between older boost libraries, an individual library can't drop c++03 support without this decision affecting many, many other boost libraries. And while external users that can't migrate to c++11 have the option to just stick to an older boost version, internal users (aka other boost libraries depending on it) can't do that. So, let's say the maintainer of Boost.iterator wants to drop c++03 support and start using c++11 features. That would mean that at least a dozen or so other libraries that depend on it would suddenly also no longer be c++03 compatible without them having any say in it. If I were a boost library maintainer I'd certain not want to make the switch to c++11 under those conditions, even if I'd do it with a standalone library for which I can just release a new major version. This is, why I think, such a decision needs to be made by all affected maintainers (or at least by most of them) together.

You have things backward. How can all maintainers decide what level of C++ support a particular library should have ? Library X has features which determine what level of C++ support it needs. Simply because dependent libraries A, B, and C use library X they certainly can not decide for library X what level of C++ support it should have ?

I think you do not seem to understand that a library's level of C++ support depends on the C++ language and library idioms it uses, not on some theoretical need to support some level of the C++ standard. If a library works at the C++03 level and Boost decides to "drop C++03 support" in your terms, what do you actually propose to do with such a library ?

I would really like to know your answer to that ?

For almost all c++ libraries I'm aware of, the supported minimal c++ version is a project management decision that comes first and based on that decision, the developers use the features that are available to them (or enable later features only conditionally via the preprocessor). Essentially it is a tradeoff between being usable by as many projects as possible vs doing without all the nice features that the new language standard provides

Of course, over time, project management might decide to drop support certain c++ versions as client needs change (no need to stay compatible with c++03 if none of your clients' needs that compatibility).

For boost, the clients are not only external users but also other boost libraries that might want to provide c++03 compatibility to their clients and while no one is *forced* to keep his or her library compatible to c++03, it creates a certain level of peer pressure if you know that if you start using c++11 features, the libraries that depend on you can also no longer be compiled in 03 mode or have to implement the functionality themselves (I mean no one wants to make life difficult for their colleagues right?)

...

Are you going to force it to use some C++11 on up feature in its code so that it no longer compiles at the C++03 level, even when it has no use for any C++11 on up feature anywhere in its implementation ? I am sure you realize how silly that would be. Are you going to drop the library from the list of Boost libraries even though the library works perfectly well with users who compile it with C++11, C++17, or C++20 levels ?

Where do those ideas come from?

From my initial post: ============ And before someone starts to raise straw mans: That of course wouldn't mean that a particular library *must* no longer compile in 03 mode, but one can no longer rely on the boost-internal dependencies remaining c++03 compatible. =============

or from my second mail:

============= I would certainly not expect that you start ripping out the guts of an old, battle proven library and replace everything with c++11 features just for the fun of it. =============

I don't know why this has to be repeated over and over again.

...

That would really be absurd. Do you want to make an announcement on the Boost web page that Boost libraries which support C++03 may not support that level in the future and therefore Boost end-users are encouraged to use a higher level of C++ when using Boost libraries ? That might be reasonable, but then again we can say that for any library, ie. that it might only work in the future with a higher level of the C++ standard than it currently supports. So now can you see why your suggestion of Boost "dropping support for C++03", like others in the past who have said the same thing, is so generally meaningless ? It is because practically there is nothing to be done except perhaps a general announcement on the Boost web page, and even that has no affect on libraries which support C++03 right now, nor should it.

I wonder if the reason it appears meaningless to you is because you deliberately want to misunderstand the suggestion.

No, no, no ! It is meaningless because you continue to talk about this in generalities as if it were a philosophical question that some sort of agreement is going to solve rather than offer any sort of practical example of what "dropping C++03 support" actually entails. At least Peter brought up some practical suggestions, but you just want to keep parroting some idea without offering any practical solution to what it should actually happen. You seem to think that some sort of announcement is magically going to cause a change to libraries which support C++03. Sorry to burst your bubble but that is not going to happen, nor should it. Telling some library developer/maintainer that they should use some C++11 on up feature for the sole reason that it will require that library to only work with C++11 on up is so illogical that I really can not believe a computer programmer could even think in those terms.

You as a library programmer should know better than anyone else that there is a difference between supported (and hopefully) documented API behavior, which you are committed to support and implementation details that might change at any moment (and don't get me started on UB that happens to do what you expect in a particular version of your compiler).

Currently, many libraries are committed to support c++03, meaning they won't just start to use c++11 features without prior announcement and some transition phase. After officially dropping c++03 support (with prior announcement and appropriate transition phase), whether a library happens to still compile with c++03 or not becomes an implementation detail that might or might not change with every new revision.

Best

Mike

On 8/26/2018 3:06 PM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Monday, August 27, 2018 2:33 AM

. Telling some library developer/maintainer that they should use some C++11 on up feature for the sole reason that it will require that library to only work with C++11 on up is so illogical that I really can not believe a computer programmer could even think in those terms.

For the last time: I never suggested to tell a library maintainer to use a C++11 just for the heck of it (or can you produce a quote?).

Actually I stated the exact opposite multiple times from the beginning.

And I also just explained, why I think just making an announcement and changing the documentation makes a difference even if not a single line of code is changed at that particular release.

Sorry, but from my side it really feels as if you are completely ignoring what I'm writing. Maybe I'll understand better what you want from me, once I had a good night's sleep.

You are correct in that I do not understand why making an announcement that Boost is "dropping support for C++03" is going to make any difference to anybody, when nothing further changes as far as Boost is concerned and in fact some Boost libraries continue to support C++03 simply because they do not require C++11 on up features. And if something further is actually supposed to change regarding Boost other than making such an announcement, I would love to hear about what it is from you. I do not believe in doing something for no particular reason just because someone thinks it sounds 'good'. I am also curious about what documentation is supposed to be changing when you say "changing the documentation". If I seem belligerent it is because you are only the last of a stream of people saying that Boost should "drop support for C++03" without saying what in particular this is supposed to entail, other than Boost supposedly announcing that this will be the case.

On 8/27/2018 1:47 AM, degski via Boost wrote:

On Mon, 27 Aug 2018 at 01:21, Edward Diener via Boost wrote:

...

You are correct in that I do not understand why making an announcement that Boost is "dropping support for C++03" is going to make any difference to anybody, when nothing further changes as far as Boost is concerned and in fact some Boost libraries continue to support C++03 simply because they do not require C++11 on up features.

I purposely did not post in this thread, because I already had the discussion on this list, with the same result.

I have come to a more balanced view since then. The way I see it, is that those advocating "drop C++03" have mostly one thing in mind. C++11 is a major departure from C++03, because of move semantics (the real moving, i.e. not copying stuff). I think Boost could adopt a maybe more subtle view of imposing that C++11 moves should be implemented over the board (where that makes sense of course), as a rule.

"C++11 moves should be implemented over the board". Please explain what you mean by that ?

This does not imply "drop C++03", but does mean that peops that did move to C++11 are guaranteed to get what they want when using Boost compiled with C++11 and up. I would be happy with that. IMO, the alround support of C++11 moves is a more interesting question/challenge than moving to CMake.

degski

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Monday, August 27, 2018 6:21 AM

You are correct in that I do not understand why making an announcement that Boost is "dropping support for C++03" is going to make any difference to anybody, when nothing further changes as far as Boost is concerned and in fact some Boost libraries continue to support C++03 simply because they do not require C++11 on up features.

Happy to quote myself again ================ You as a library programmer should know better than anyone else that there is a difference between supported (and hopefully) documented API behavior, which you are committed to support and implementation details that might change at any moment (and don't get me started on UB that happens to do what you expect in a particular version of your compiler). Currently, many libraries are committed to support c++03, meaning they won't just start to use c++11 features [unconditionally] without prior announcement and some transition phase. After officially dropping c++03 support (with prior announcement and appropriate transition phase), whether a library happens to still compile with c++03 or not becomes an implementation detail that might or might not change with every new revision. ================ Now, disagreeing with or not understanding my arguments is one thing, but the fact that you keep completely ignoring what I'm saying or even worse insinuating that I would suggest things when I actually stated the exact opposite makes me wonder if you try to have a discussion with me or rather just reflexively answer to anything that contains "drop support for C++03" with some default statements of yours, because I'm just the next guy suggesting to "drop c++03 support".

And if something further is actually supposed to change regarding Boost other than making such an announcement, I would love to hear about what it is from you. I do not believe in doing something for no particular reason just because someone thinks it sounds 'good'.

I am also curious about what documentation is supposed to be changing when you say "changing the documentation".

If I seem belligerent it is because you are only the last of a stream of people saying that Boost should "drop support for C++03" without saying what in particular this is supposed to entail, other than Boost supposedly announcing that this will be the case.

That is the point: It is not supposed to entail anything more than that. Now, there are a lot of things I *would like to do* if support for c++03 is dropped on a boost wide level, such as - Deprecating libraries and types that have been merged into the standard (why spend the effort of maintaining them). - Removing internal dependencies when they can be replaced with c++11 standard library or language constructs - Remove conditional compilation paths - Reduce test matrix (removing all compilers that can't compile in c++11 mode and making sure every test is compiled with at least c++11) - Migrate libraries from mpl to mp11 - Simplify some code paths where possible. A library might not require c++11 features, but almost any library I've seen can profit from c++11. (some of those changes I actually have already done in private forks of boost libs) But regardless of what is discussed and/or decided on the ml, none of the library maintainers could be forced to accept any of those changes anyway so I don't see the point of discussing those here. I'd rather discuss specific changes with the responsible maintainer in an issue/PR at the respective github repository. However, officially dropping c++03 support (boost wide) would get rid of problems like this this: "Oh I'd like to apply that change to library A, but that requires at least c++11 and the boost libraries X,Y,Z depend on A compiling in c++03 mode, so I can't do it without announcing the switch on the ml and then wait for a year or so until they have found an alternative - so sorry, but that's just not worth it" because if your library is not officially supporting c++03, no one should rely on that anyway regardless of whether it works at the moment or not and if they do rely on it anyway, it is their problem. (see my above argument about supported API behavior vs implementation details)

I am also curious about what documentation is supposed to be changing when you say "changing the documentation".

I think you started mentioning changing the documentation first, but either way, what I'd expect is a note *along the lines of*: "This library is supporting compilers x, y, z and supports c++11 and upwards language standards. Compilation with an older compiler or in c++03 mode may be possible, but is not supported any may break with any new release without prior notice." @degski Personally, I'm much more interested in code simplification and reduction of dependencies than (run-time) speed improvements, but of course others have different priorities. Best Mike

Glen Fernandes вроте:

Do you have an example of a Boost library author or maintainer that has refused (either a pull request, or a other feature request) to leverage C++11+ features (after detecting them with Boost.Config, of course) to provide some more optimal implementation in their library, or provide a new feature their library?

There are Boost libraries are committed to supporting C++03, but they also leverage C++11, C++14, C++17 features when available, because this is what those particular library authors/maintainers are happy to do. (Myself included: I would not refuse to take advantage of a C++17 feature for C++17 users, while still supporting C++11 for C++11 users).

Doing this in a header-only library is a recipe for (usually asymptomatic) ODR violations, if the library is used by two translation units with different cxxstd settings, as I pointed out recently. But that's not the point, is it? The point is, f.ex. that Boost.Test can't drop C++03 and use rvalue references and std::function in its interface (also something we discussed), because it's Boost Test, which other libraries use in their tests. Since we (Boost) officially support C++03, we run tests with C++03, and Boost.Test has to support C++03. If we (Boost) dropped C++03 support, meaning that we no longer support `b2 install` to work with a C++03 compiler and we no longer run (our own) regression tests under C++03 compilers, Boost.Test, and each and every one of its dependencies would now be free to drop C++03 support. In addition, we may start retiring libraries that have a standard equivalent, such as f.ex. boost::function. Or we may not - it'd be up to us to decide. But we would be able to do it if we wanted to. (And of course migrate mpl use to mp11. :-) )

On 8/27/2018 12:29 PM, Peter Dimov via Boost wrote:

Glen Fernandes вроте:

...

Do you have an example of a Boost library author or maintainer that has refused (either a pull request, or a other feature request) to leverage C++11+ features (after detecting them with Boost.Config, of course) to provide some more optimal implementation in their library, or provide a new feature their library?

There are Boost libraries are committed to supporting C++03, but they also leverage C++11, C++14, C++17 features when available, because this is what those particular library authors/maintainers are happy to do. (Myself included: I would not refuse to take advantage of a C++17 feature for C++17 users, while still supporting C++11 for C++11 users).

Doing this in a header-only library is a recipe for (usually asymptomatic) ODR violations, if the library is used by two translation units with different cxxstd settings, as I pointed out recently.

How many times do you think anyone compiles more than one TU with different cxxstd settings ? And how is this ever anything but a user error ?

But that's not the point, is it? The point is, f.ex. that Boost.Test can't drop C++03 and use rvalue references and std::function in its interface (also something we discussed), because it's Boost Test, which other libraries use in their tests. Since we (Boost) officially support C++03, we run tests with C++03, and Boost.Test has to support C++03.

I do not see technically why Boost Test can not have rvalue references and std::function for C++11 users on up while still maintaining an interface that C++03. But I understand that such implementing such functionality might be a PITA to do. So I am certainly not against dropping support for C++03 in Boost Test or even dropping support for regression testing or CI testing of libraries at the C++03 level.

If we (Boost) dropped C++03 support, meaning that we no longer support `b2 install` to work with a C++03 compiler and we no longer run (our own) regression tests under C++03 compilers, Boost.Test, and each and every one of its dependencies would now be free to drop C++03 support.

That is fine with me personally. If it ticks off end-users, that you would not be able to create a shared/static Boost library at the C++03 level, you can answer them <g>.

In addition, we may start retiring libraries that have a standard equivalent, such as f.ex. boost::function. Or we may not - it'd be up to us to decide. But we would be able to do it if we wanted to. (And of course migrate mpl use to mp11. :-) )

I wonder who wrote mp11 ? The main problem as always is to put resources where there are needed. I am not against Boost saying that we are "dropping support for C++03", if we actually explain to end-users what this entails and it actually entails something significant so that announcing that Boost is "dropping support for C++03" is not just a psychological ploy to get end-user to use C++11 on up with Boost. If we just wanted to use words to encourage Boost end-users to use more modern C++ standard levels than C++03 in their code we could write something like "We encourage Boost users to use C+11 on up standard compiler levels with their compiler as Boost resources go to libraries which support those levels and a number of Boost libraries can not be used at any lower level." That is much different from saying that "Boost is dropping support for C++03" if we do not explain specifically what the latter actually means.

On 8/27/2018 2:13 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

That is much different from saying that "Boost is dropping support for C++03" if we do not explain specifically what the latter actually means.

If I post "Boost is dropping support for C++03" f.ex. on Twitter or Reddit, every single user will immediately understand what that means. :-)

I am not a participant of either so some of your humor is lost on me, but I can guess that it suggests that you do not consider the intelligence of the average Twitter or Reddit participant to be very high.

On Mon, Aug 27, 2018 at 9:09 PM Alexander Grund via Boost < boost@lists.boost.org> wrote:

PS: As HPC Systems came up: They usually count in decades. GCC 4.8 was released in 2013, so rule of thumb would be that at about 2023 everyone is using GCC 4.8+. But you can also look for RHEL support (https://access.redhat.com/solutions/19458) RHEL 7 uses GCC 4.8 where RHEL 6 is supported till end of 2020 (not counting extended support)

The OS that's running those systems do ship those ancient compilers. Luckily for us, almost all Supercomputers I work on, do have newer compiler versions installed via a modules environment. If you are required to use gcc 4.x, you problem have more pressing issues than Boost 1.7x doesn't officially support C++03 anymore. And maybe, you can't even use C++ in those scenarios

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Tue, 28 Aug 2018 at 11:59, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

AFAIK compilers have improved a lot so using old compilers seems a bit weird.

The cross-section of people that want to use the latest Boost with the oldest working compiler cannot be enormous. But that seems to be the group (is there more than 1 user like that?) we are worried about here. Indeed, weird. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

On Tue, 28 Aug 2018 at 13:50, Glen Fernandes wrote:

On Tuesday, August 28, 2018, degski wrote:

...

On Tue, 28 Aug 2018 at 11:59, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

...

AFAIK compilers have improved a lot so using old compilers seems a bit weird.

The cross-section of people that want to use the latest Boost with the oldest working compiler cannot be enormous. But that seems to be the group (is there more than 1 user like that?) we are worried about here. Indeed, weird.

It is not enormous but it is big enough that as a Boost maintainer I still want to support them.

Weird to a Boost user, sure. Not very weird to those Boost library authors that are contacted by such users.

As I've even been mentioned before, even certain projects at Microsoft (some that I actually worked on), still update Boost while supporting older VC compiler versions.

I'll take your word for it, weird people everywhere. Well MS never stops surprising us, not so long ago [like this year] they did an update of, cannot remember exactly, of paint.exe maybe (or something similar). They actually did an edit (with a hex-editor) of this binary (it fixed the problem) and sent it out as an update (which it was), but they must have either lost the source code, or had no way of compiling the code. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

On Tue, Aug 28, 2018 at 7:19 AM Olaf van der Spek wrote:

Part of the problem is that there's no data / visibility on this. Who's using what compilers? When do they plan to move forward?

Why is lack of data or visibility on this a problem for you?

And what costs do others incur for (some of) Boost having to keep supporting this too?

...

What will change if we (Boost) make that announcement tomorrow? It's still up to the library maintainer.

Is it? If one of your dependencies requires C++11...

Sure. Let's say library Boost.Library today depended on Boost.Core for boost::addressof and Boost.TypeTraits for boost::aligned_storage - tomorrow and both Boost.Container and Boost.TypeTraits choose to break C++03 compatibility: Tomorrow, if Boost.Library's maintainer is still interested in supporting C++03 users, they will just provide the above in boost::library::detail::addressof and boost::library::detail::aligned_storage (either from the existing implementations or their own). i.e. Even if we announce any such thing, it is still up to the maintainer of Boost.Library to drop C++03 support. This might help push them in that direction if they don't want the maintenance burden sure, but it is no guarantee, especially if their users are more important to them. Glen

On Tue, Aug 28, 2018 at 7:37 AM Olaf van der Spek wrote:

On Tue, Aug 28, 2018 at 1:32 PM, Glen Fernandes wrote:

...

On Tue, Aug 28, 2018 at 7:19 AM Olaf van der Spek wrote:

...

Part of the problem is that there's no data / visibility on this. Who's using what compilers? When do they plan to move forward?

Why is lack of data or visibility on this a problem for you?

How would we know whether somebody is depending on something without data?

Who is the 'we' here? As a Boost user, why is that lack of data a problem for you? What will you do different if you had that data?

...

...

And what costs do others incur for (some of) Boost having to keep supporting this too?

...

What will change if we (Boost) make that announcement tomorrow? It's still up to the library maintainer.

Is it? If one of your dependencies requires C++11...

Sure. Let's say library Boost.Library today depended on Boost.Core for boost::addressof and Boost.TypeTraits for boost::aligned_storage - tomorrow and both Boost.Container and Boost.TypeTraits choose to break C++03 compatibility: Tomorrow, if Boost.Library's maintainer is still interested in supporting C++03 users, they will just provide the above in boost::library::detail::addressof and boost::library::detail::aligned_storage (either from the existing implementations or their own).

i.e. Even if we announce any such thing, it is still up to the maintainer of Boost.Library to drop C++03 support. This might help push them in that direction if they don't want the maintenance burden sure, but it is no guarantee, especially if their users are more important to them.

Even if Boost.Config or .Test move to C++11? Would it be a free choice for the maintainers of those libs if they know a lot of libs depend on them?

Yes. 1. So many Boost libraries do not even use Boost.Test, and instead use Boost.Core.Lightweight_Test for testing, so that one: I have no doubt a library maintainer could migrate away it from if they have need to. 2. As for Config, it never needs to move away from any C++ version, it's just macros for detection that will never impact the user of library Boost.P or even how clean or maintainable library Boost.Ps code looks Glen

-----Original Message----- From: Boost On Behalf Of Glen Fernandes via Boost Sent: Tuesday, August 28, 2018 6:51 PM

On Tuesday, August 28, 2018, degski wrote:

...

The cross-section of people that want to use the latest Boost with the oldest working compiler cannot be enormous. But that seems to be the group (is there more than 1 user like that?) we are worried about here. Indeed, weird.

It is not enormous but it is big enough that as a Boost maintainer I still want to support them.

Important data point thank you! I started a separate thread with a "survey" (well, 6 yes/no questions), if you have the time, could you please also answer there?

Weird to a Boost user, sure. Not very weird to those Boost library authors that are contacted by such users.

As I've even been mentioned before, even certain projects at Microsoft (some that I actually worked on), still update Boost while supporting older VC compiler versions.

Maybe I'm mixing this up but I vaguely remember a post some time ago about this topic (could be that it was actually on reddit thought). In any case, is this information still current? The post I have in mind mentioned that that information was from "a few years ago" (again, I might completely misremember or mixing it up). Best Mike

Alexander Grund via Boost schrieb am Di., 28. Aug. 2018 12:46:

...

...

PS: As HPC Systems came up: They usually count in decades. GCC 4.8 was released in 2013, so rule of thumb would be that at about 2023 everyone is using GCC 4.8+. But you can also look for RHEL support (https://access.redhat.com/solutions/19458) RHEL 7 uses GCC 4.8 where RHEL 6 is supported till end of 2020 (not counting extended support) I'm wondering, do those projects require the latest version of Boost? And why can't they use later versions of compilers? AFAIK compilers have improved a lot so using old compilers seems a bit weird. No, for the same reasons: Not old enough. So thinking about that it should be fine. For why: Management and compatibility: We want to build something here that is guaranteed to run there so we have to keep the requirements to the bare minimum. No point in arguing, I tried...

Now I'm really curious. Apart from the compiler shipping with the OS (RHEL or similar), most HPC systems do have newer compiler versions installed.

From a recent version of the Intel compiler to gcc and nowerdays even clang. Which requirements do we talk about here?

Edward Diener wrote:

On 8/27/2018 2:13 PM, Peter Dimov via Boost wrote:

...

If I post "Boost is dropping support for C++03" f.ex. on Twitter or Reddit, every single user will immediately understand what that means. :-)

I am not a participant of either so some of your humor is lost on me, but I can guess that it suggests that you do not consider the intelligence of the average Twitter or Reddit participant to be very high.

No, that's not at all what I meant. I meant what I said. Users will immediately understand "Boost is dropping support for C++03".

On Mon, Aug 27, 2018 at 8:00 PM Edward Diener via Boost < boost@lists.boost.org> wrote:

The main problem as always is to put resources where there are needed. I am not against Boost saying that we are "dropping support for C++03", if we actually explain to end-users what this entails and it actually entails something significant so that announcing that Boost is "dropping support for C++03" is not just a psychological ploy to get end-user to use C++11 on up with Boost.

A concrete example of dropping C++03 support is boost.asio (with boost-1.68.0). At least its abstraction and customization point over buffers now use C++11. A concrete issue that could be solved by "dropping C++03" is being able to use std::error_code while also using boost.asio (and possibly boost.filesystem). Since they use boost.error_code, they (effectively) force you to also use boost.error_code in your application. That said, there clearly are benefits to staying API compatible between boost releases, and switching boost.error_code for std::error code in boost.asio and boost.filesystem would be quite a pain to upgrade (and for clients to support multiple boost versions). -- Arvid Norberg

On 8/27/18 15:39, Gavin Lambert via Boost wrote:

On 28/08/2018 05:59, Edward Diener wrote:

...

How many times do you think anyone compiles more than one TU with different cxxstd settings ? And how is this ever anything but a user error ?

Literally almost every Boost user on Linux does that (unless they compile Boost from source themselves).

I never do this. In fact, this is "doing it wrong". Software developers who do not build dependencies for their C++ programs and instead rely on package managers are "doing it wrong". /me waits for the flame. michael -- Michael Caisse Ciere Consulting ciere.com

On 28/08/2018 10:55, Michael Caisse wrote:

On 8/27/18 15:39, Gavin Lambert wrote:

...

On 28/08/2018 05:59, Edward Diener wrote:

...

How many times do you think anyone compiles more than one TU with different cxxstd settings ? And how is this ever anything but a user error ?

Literally almost every Boost user on Linux does that (unless they compile Boost from source themselves).

I never do this. In fact, this is "doing it wrong". Software developers who do not build dependencies for their C++ programs and instead rely on package managers are "doing it wrong".

While I don't entirely disagree with the sentiment, all this does is to impose compatibility headaches on the package maintainers (perhaps of the "successfully links but causes UB that nobody notices for a while" kind, which can end up as more headaches for *you*), or end up with very old versions of your packages being distributed because the newer ones aren't compatible with the standard compilation of their dependencies. And I suspect the vast majority of application developers do indeed rely on using "-dev" or "-devel" packages or the equivalent.

On 28/08/2018 12:11, Michael Caisse wrote:

On 8/27/18 16:11, Gavin Lambert wrote:

...

While I don't entirely disagree with the sentiment, all this does is to impose compatibility headaches on the package maintainers (perhaps of the "successfully links but causes UB that nobody notices for a while" kind, which can end up as more headaches for *you*), or end up with very old versions of your packages being distributed because the newer ones aren't compatible with the standard compilation of their dependencies.

Rule #1 to reduce headaches in distribution: statically link

If you're distributing binaries alone, sure. I don't know about other distributions, but both Debian and Ubuntu (the latter of which is one of the most popular desktop distributions, AFAIK) explicitly discourage use of static libraries for standard open-source packages. For that matter, so does ld -- if it finds both a shared library and a static one at the same location, it will always use the shared one.

On 28/08/2018 17:11, Mike Dev wrote:

throughout this thread you keep saying that you or the user will not understand what

"dropping c++03 support"

means and I have to say I find that very hard to believe, as the concept of "XXX is not supported" is ubiquitous throughout software development.

There are of course differences in detail, but universally it always means something along the lines of

"We don't promise that XXX works. When you try XXX you are on your own, we take no responsibility for what happens if you do and even if it works now, it might not work with the next product version (even if it is just a minor/path update)."

Now, on top of that, "XXX is not supported" often means that "XXX really just doesn't work", but I can give you dozens (probably thousands) of examples where things that are not officially supported happen to work e.g.:

There is a significant difference between "we've never tried it on XX and so we don't support it", and "it used to support XX and now doesn't". You are trying to cite cases of the former but it is actually the latter. Without further explicit clarification, that invariably means "we have decided to start doing things that do not work in XX", ie. that people can definitely no longer use XX. Besides, even if in the short term immediately following that announcement, no library changes are made which actually break compatibility; it still seems like there is no point in making such an announcement unless the goal is to indeed break compatibility. Pretending otherwise is silly. (I'm not actually opposed to that, for what it's worth. I do have some code that's stuck pre-C++11 but it's also going to be stuck on an older Boost release, so it's not an issue.)

On Tue, 28 Aug 2018 at 10:08, Alexander Grund via Boost < boost@lists.boost.org> wrote:

As Boost consists of multiple, almost independent libraries (different maintainers), it means that those libs will be C++03 incompatible at different times.

But the inter-dependencies are many. vcpkg allows for "modular Boost". So, as it's one of my favorite libraries I installed Boost.Containers, just that. Ooops, I just pulled in 26 "modules". From there I quickly decided to drop that idea and just install Boost, the lot. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

On 28/08/18 11:29, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Gavin Lambert via Boost Sent: Tuesday, August 28, 2018 1:34 PM

There is a significant difference between "we've never tried it on XX and so we don't support it", and "it used to support XX and now doesn't".

You are trying to cite cases of the former but it is actually the latter. Without further explicit clarification, that invariably means "we have decided to start doing things that do not work in XX", ie. that people can definitely no longer use XX.

Personally, I don't think this makes it any more difficult for the user to understand what is going on. The announcement could be something like

"Starting from version XX we no longer support c++03"

And the documentation of any library in XX that is willing to make the switch could state something like

"We no longer support compilation in c++03 mode".

Irrespective of whether a particular library can still be compiled in c++03 mode in a particular version, I don't see how this can be interpreted any differently than

"I shouldn't rely on XX working in my c++03 project anymore"

which is exactly, what it is supposed to mean. Nothing more, nothing less.

[A few comments from an end user.] In the projects I've maintained, where we already made the transition to C++11 and later to C++14, this is exactly what we meant. Some sub-components might have still functioned with C++03, but we ceased to test this worked, and we didn't make any guarantees that we wouldn't start using C++11 or 14 features in point releases. NB. We specified "C++11" and "C++14" as the subset of C++11 and C++14 features supported by specific versions of GCC, Clang and MSVC, so it was clear what the expectations were, and exactly what we would support, to avoid using language or library features which weren't available across the board (modulo special-casing with e.g. #ifdefs if appropriate). Example: std::regex was buggy with several GCC releases, so boost::regex continued to be used as a fallback. We never had any complaints. While we had multiple sub-components (much less than Boost though), we always specified the minimum version across the entire project rather than allowing individual components to specify different requirements. This is partly practical--the CI systems we provision have a cost to set up and maintain, but also it sets expectations for end users, maintainers and contributors and makes it clear what's supported and permitted, and what is not. For a project the size of Boost, it would be useful to set this minimum requirement top down across the board. A comment about C++03 compatibility. It has a cost, and this is one example of it: https://www.reddit.com/r/cpp/comments/99cggw/boostmultiindex_introducing_c17... This is a discussion about Boost.MultiArray. I've been running into several problems with MPL over the last few years, and it became so problematic that I ripped out Boost.Variant and replaced it with mpark::variant as a prelude to C++17 std::variant. The MPL dependency was the sole reason for this. MPL is a huge pain when you need to redefine the container size limits. It can interfere with other MPL-using types, and if used in a public header can interfere with any other library also using MPL. It becomes a fragile mess which you can make work with horrible hacks to the include order for some cases. But a new Boost release can break it all over again if the include order changes. C++11 variadic templates make MPL completely redundant. Is Boost aiming to be up to date and useful for present needs, or is it going to be tied to the past and be second-rate? What I mean is, libraries like Variant and MultiArray are inferior to more modern reimplementations which aren't tied to Boost. It's a shame that the Boost implementations have stagnated and aren't best in their class. Dropping C++03 would permit them to drop the MPL dependency. This is not to disparage the maintenance of these Boost components. The rationale behind the current approach is sound, and the effort to maintain backward compatibility is commendable. However, C++11/14 compilers have become standard, and these compatibility compromises are now increasingly a hindrance; the benefit of them becomes moot as they become increasingly irrelevant. Many components could also be updated to use standard language and library features, dropping a huge amount of legacy cruft which has real negative consequences for end users. Regarding some of the comments about platform compatibility, I support C++11 and 14 on several Ubuntu LTS, CentOS, Clang with Xcode and FreeBSD, and MSVC releases. For CentOS 7 (and 6), as others mentioned, we have Devtoolset-7 and EPEL, which provide updated versions compatible with the base platform. Unfortunately, the base platform also includes Boost 1.53 which EPEL won't ever update. So we are stuck with 1.53 for the lifetime of CentOS 7 if we wish to be compatible with the base platform. So in practice if Boost > 1.68 drops support for C++03, it has zero practical effect due to the existing requirement to use 1.53. The same applies to all the other platforms which also provide Boost; we use the provided version for compatibility unless there's no alternative. BSD ports and MacOS homebrew are usually pretty current. On Windows/MSVC we build the latest Boost, but that's not strictly required, we could stay behind a release or two and patch if needed. If I had to support a platform with an older compiler after Boost dropped C++03 (or later) compatibility, I would simply build the last Boost release supporting that compiler. While the latest Boost release is nice to have, IME it's rarely been the case that it's essential due to the need to support several years of Boost versions provided by various Linux distributions and other package managers. If the next Boost release required C++11 (or even 17), it wouldn't be the end of the world, I would simply continue to use 1.67/1.68. Kind regards, Roger

On 28/08/18 16:17, Edward Diener via Boost wrote:

On 8/28/2018 1:11 AM, Mike Dev via Boost wrote:

...

Dear Edward,

throughout this thread you keep saying that you or the user will not understand what

    "dropping c++03 support"

means and I have to say I find that very hard to believe, as the concept of "XXX is not supported" is ubiquitous throughout software development.

It astounds me that you can not understand that the statement "Boost dropping c++03 support" is a generality that can mean whatever you think it means, and that you keep pushing for such a statement being universally understand by everyone with no further explanation needed. As you can clearly read by other respondents in this thread, and not just me, you are dead wrong in your assumption. When some poor end-user reads "Boost dropping c++03 support" and finds he is still able to compile some Boost library in C++03 mode and asks why a statement was made of "Boost dropping c++03 support", I nominate you as the one to explain to him that

"Not supported" does not mean "not functional". It means that it's... not supported by the project's developers. If it does by chance happen to work, there are no guarantees that it works correctly or will continue to work correctly. The risk of using it is entirely in the hands of the end user. For several of the projects I work, or have worked, on there are plenty of platforms and configurations which work perfectly well in practice but aren't supported at all. We have to constrain ourselves to a limited subset of the possible to provide meaningful support to our users/clients, typically the platforms and configurations they care about, and if an end user steps outside that supported subset of possibilities then they do so on their own at their own risk. The organisation/company would not /officially/ support such use. Incidentally, in my previous role we had a lifecycle of support for all dependencies including compilers and libraries which was broadly: unsupported (new) [not yet tested or qualified] supported (newer versions) supported (recommended) [preferred version] supported (older versions) supported (deprecated) unsupported (old) unsupported (known broken) If C++03 is currently "supported (older version)" then it could be moved to "supported (deprecated)" to officially deprecate it. If C++11 became a hard requirement which would break C++03 support then it would become "unsupported (known broken)" or else it would be "unsupported (old)" (untested, but might work). We would have a matrix of each of GCC, Clang, MSVC and Boost versions (as well as all other dependencies) with our product versions on the other axis so that it was clear what was supported for every version, and made it clear what the support window was for existing and future releases. You would see new GCC, Clang, MSVC and Boost releases go through all the above phases over time with new product releases. Regards, Roger

On 8/28/2018 1:50 PM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Tuesday, August 28, 2018 11:18 PM

It astounds me that you can not understand that the statement "Boost dropping c++03 support" is a generality that can mean whatever you think it means, and that you keep pushing for such a statement being universally understand by everyone with no further explanation needed.

So, if you actually agree with the suggestion I'm making and all you want is to put a more detailed explanation on the boost website than what I sketched in my previous posts, I'm sure we can work something out.

...

As you can clearly read by other respondents in this thread, and not just me, you are dead wrong in your assumption.

I think except from you, there was exactly one other post (from Gavin) that said "dropping c++03 support" maybe unclear to the user. That is certainly not enough evidence that I am dead wrong. But as I said (just now, as well as in my answer to Gavin), we can certainly talk about what exactly should be written once you decided if you want to actually support the suggestion.

...

When some poor end-user reads "Boost dropping c++03 support" and finds he is still able to compile some Boost library in C++03 mode and asks why a statement was made of "Boost dropping c++03 support", I nominate you as the one to explain to him that

'the concept of "XXX is not supported" is ubiquitous throughout software development'

and therefore he is a fool to ask such a question.

As I still don't believe this will be a common problem - sure. Put my email address under whatever text we come up with in the end (I somewhat doubt though that you want me to speak for the boost community)

...

I do not know whether I agree with your suggestion

Deciding that question either way would actually be more useful than our ping pong of "the description is unclear" / "it is clear".

...

BTW I am not against Boost actually doing specific things which promote C++11 on up library development or use of C++11 on up for end-users who use Boost libraries. But those specific things, whatever is decided, need to be explained to end-users and not just a statement that "Boost is dropping C++03 support".

So do you have any other suggestion for such a specific ting that would promote c++11 library development? If not, lets stick to the suggestion at hand.

Other than not removing useful Boost libraries which support c++03 as well as all subsequent C++ standard levels, and not telling people that they can not use such libraries in c++03 mode if they actually want to do so, I am perfectly willing to let others, including yourself, decide the best way in which support for c++03 in Boost is reduced. My argument has always been that putting a generalized statement on the website, without explaining what it actually entails as far as using Boost libraries is concerned, is going to lead to confusion and puzzlement from end-users and endless questions. What can it possibly cost to actually explain of what "Boost dropping support for c++03" actually consists, when it is finally decided what Boost is going to do in this area ? If it is a matter of correct grammar or exposition in the explanation, I will gladly volunteer to write it if no one else wants to do so.

Best

Mike

I thought Peter Dimov got it right from the comment I saw earlier. The project would no longer spend time and effort on qualifying or testing C++03 compatibility. CI builds and the test matrix would no longer specifically test C++03. The default language level for b2 builds would be C++11. +1 Folks consuming boost can always hold back their boost upgrades to stay with C++03 and they can weigh the pros and cons of staying on C++03 versus moving forward. As a developer both working on and consuming boost I would appreciate the permission to start using C++11 without fear.  +1 and as already said: The cross-cut of C++03 & latest-boost users is

probably very small. (If they can update Boost to latest, why not compilers to "not ancient"?) So can we stop discussing "what does dropping... mean", reiterating the obvious benefits and start talking about when and how?

On 8/30/2018 8:02 AM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Alexander Grund via Boost Sent: Wednesday, August 29, 2018 3:12 PM

So can we stop discussing "what does dropping... mean", reiterating the obvious benefits and start talking about when and how?

Not sure, if I would call this a done deal yet and before any final decision is made, the thread should probably be open for more than a few days anyway.

However, there seems to be enough momentum and acceptance to push on and for now and for that we probably need some concrete text for the announcement (if it happens). Based on what King wrote earlier I would suggest something like the text below. Assuming everyone is happy with the general content, maybe Edward or someone else could take care of fully flashing this out (or write something completely different if you don't like it).

In general terms, I'd be happy to push this topic forward, but as I am in no way associated with boost except starting this thread, it may be best if someone else would take the lead. Also, I probably won't be able to write any more emails till end of next week.

The "pushing on" probably needs someone from the Boost steering committee involved.

Anyway here is my suggestion for the text: ===========================================

...

[Add some fluff here?]

Starting from the first release of 2020 (probably 1.73) boost will officially drop c++03 support.

What does that mean?

First of all, on a general project level, no more time and effort will be spend on qualifying or testing C++03 compatibility. Specifically, - The default language level for b2 builds will be at least c++11 (if the compiler's default or the particular library doesn't specify a later version anyway) - c++03 builds and compiler that don't support at least c++11 will be removed from the regular build matrix - for CI tests as well as for release testing. - Problems that only manifest on not supported compilers [1] or in c++03 mode will not block a release, and will probably not be fixed at all. - Prebuild binaries on windows will only be provided for supported compilers *[1]*

Second, individual libraries that are currently supporting c++03 may start to use c++11 features unconditionally without prior notice or further transition period. As always, individual library maintainers are of course free to continue their support of older language versions and compilers and we generally don't expect the introduction of a lot of new c++11 code without a clear benefit. However, many libraries may become incompatible with c++03 just by virtue of depending on another library that previously supported 03 but now starts to use c++11 features.

Obviously, this change will only effect libraries that have supported c++03 before. Libraries that already supported compilers and/or newer language versions are unaffected.

If you want to continue to use boost in a project that has to stay compatible with c++03, recommendation is to stick to the last release before the switch (probably 1.72).

[add some more fluff?]

[1] We only consider the following compilers/toolchains to have sufficient c++11 support to be supported: - MSVC 2015 and up, - gcc 4.9 and up, - clang3.3 and up (when paired with an appropriate standard library implementation) - [ICC? CUDA? Any other?]

I would emphasize what toolchains are actually tested rather than supported toolchains. In general developers/maintainers care much less about toolchains than they do about C++ compiler levels and features in their library. If we say that we do not support Intel or Oracle compilers, for example, we are denigrating toolchains that may well work fine with most Boost libraries. If we explain which toolchains we regularly test, this then is an impetus for certain toolchains which we do not regularly test to offer ways/means to have those toolchains tested against Boost libraries. The more toolchains we can successfully test against Boost libraries the more end-users we have.

...

============================================

Then, the documentation for each library should contain something like

============================================

...

This library supports the following toolchains and language versions

- [...]

Other toolchains might work too, but are not tested and even if they work with the current release, they might stop working with without prior notice.

It is very difficult, if not impossible, for a library to know what toolchains are supported by that library. I agree that language level should be either in the documentation directly and/or in the meta information for each library, preferably both if the meta information can enable the Boost web pages to list the language level and/or language features used for each library.

=============================================

Many (most? all?) libraries already have something like this anyway, but from 1.74 onwards (or whatever the version will be), I'd recommend to only mention pre-c++11 toolchains, if the maintainer is really committed to ensure compatibility for the next couple of releases, including internalizing any dependencies that might start to use c++11 in that time frame.

Two final notes from my part:

- First release in 2020 is just my initial proposal. If there is a desire to apply that new policy earlier (e.g. end/mid of 2019) that’s of course fine by me too. Considering how previous discussions on that topic went down I didn't want to suggest anything too aggressive, but still soon enough to have any meaning at all. Also, I wanted the policy change enacted before people would have to support yet another standard (there will likely be more removals and deprecations from the standard library in c++20).

- If this goes through, could someone create a c++11 branch (or similar) in the github main project, where libraries that want to start early can make their expected changes easily visible to others?

I think a c++11 branch as you have described brings an unneeded complication. Any library which currently supports c++03 and wants to use c++11 features will just do so. Since we wouldn't officially be testing at the c++03 level there is nothing further to do in transitioning, and each library developer/maintainer can continue to do his own local testing as he wants anyway. Thanks ! I think your text is generally excellent.

Destroy!

Mike

> -----Original Message-----
> From: Boost  On Behalf Of Glen Fernandes via Boost
> Sent: Thursday, August 30, 2018 11:55 PM
> 
> On 8/30/2018 8:02 AM, Mike Dev via Boost wrote:
> > [snip]
> 
> Looks generally good. A few things:
> 
> > [Add some fluff here?]
> 1. No fluff.

Well, I imagined that there would be some "Hello everyone, we hereby announce ..."
but that should probably be added by whomever or whatever entity actually does
the announcement
> 
> > - Problems that only manifest on not supported compilers [1] or in c++03
> >   mode will not block a release, and will probably not be fixed at all.
> 
> 2. Just "will not block a release". No "probably not be" part. This
> announcement does not need to speculate on what individual library
> maintainers will do. Let users contact the library maintainers if they
> want that support.

agreed

> 
> > As always, individual library maintainers are of course free to continue
> > their support of older language versions and compilers and we generally don't
> > expect the introduction of a lot of new c++11 code without a clear benefit.
> 
> 3. This should also just end at the "free to continue their support of
> older language versions and compilers" part. No "and we generally
> don't" part. If a library maintainer wants to introduce new C++11 and
> break compatibility, the users should not be given avenue for
> complaint if they feel it is "without clear benefit".

agreed, I was just sticking to the points mentioned by James E. King,
but not all of that needs to be in the announcement

> 
> > However, many libraries may become incompatible with c++03 just by virtue of
> > depending on another library that previously supported 03 but now starts to
> > use c++11 features.
> 
> 4. Drop this part entirely. If a library stops working in C++03 mode,
> it stops working. Users can contact the library maintainer and ask for
> them to support C++03. If Boost.X fails in C++03 mode because it
> depends on Boost.Y, the users don't need to care that the reason it
> fails is because of Boost.Y, their point of contact is Boost.X's
> library maintainer.

I somehow felt this is important, but I don't remember why just now. 

> 
> > Obviously, this change will only effect libraries that have supported c++03
> > before. Libraries that already supported compilers and/or newer language
> > versions are unaffected.
> 
> 5. This seems obvious and not worth mentioning, but up to you.

I also wasn't sure about that. I didn't want to give the impression 
that from now on every boost library would start to support c++11

> 
> > If you want to continue to use boost in a project that has to stay compatible with
> > c++03, recommendation is to stick to the last release before the switch
> > (probably 1.72).
> 
> 6. Drop this part too. Users who want to be on latest Boost because
> they use Boost.X C++11+ library and Boost.Y C++03-compatible library
> should feel equally encouraged to do.

Fine with me

> 
> > [add some more fluff?]
> 
> 7. Same as #1. No fluff.

OK

Again, please someone else take the lead on the actual writing, as I won't be able to work on this during the next week
or so (no access to a computer) a. 

Best 

Mike

On 8/30/2018 2:25 PM, Glen Fernandes via Boost wrote:
> On Thursday, August 30, 2018, Mike Dev via Boost 
> wrote:
> 
>>> -----Original Message-----
>>> From: Boost  On Behalf Of Glen Fernandes
>> via Boost
>>> Sent: Thursday, August 30, 2018 11:55 PM
>>>
>>> On 8/30/2018 8:02 AM, Mike Dev via Boost wrote:
>>>> [snip]
>>>
>>> Looks generally good. A few things:
>>>
>>>> [Add some fluff here?]
>>> 1. No fluff.
>>
>> Well, I imagined that there would be some "Hello everyone, we hereby
>> announce ..."
>> but that should probably be added by whomever or whatever entity actually
>> does
>> the announcement
>>>
>>>> - Problems that only manifest on not supported compilers [1] or in
>> c++03
>>>>    mode will not block a release, and will probably not be fixed at all.
>>>
>>> 2. Just "will not block a release". No "probably not be" part. This
>>> announcement does not need to speculate on what individual library
>>> maintainers will do. Let users contact the library maintainers if they
>>> want that support.
>>
>> agreed
>>
>>>
>>>> As always, individual library maintainers are of course free to
>> continue
>>>> their support of older language versions and compilers and we
>> generally don't
>>>> expect the introduction of a lot of new c++11 code without a clear
>> benefit.
>>>
>>> 3. This should also just end at the "free to continue their support of
>>> older language versions and compilers" part. No "and we generally
>>> don't" part. If a library maintainer wants to introduce new C++11 and
>>> break compatibility, the users should not be given avenue for
>>> complaint if they feel it is "without clear benefit".
>>
>> agreed, I was just sticking to the points mentioned by James E. King,
>> but not all of that needs to be in the announcement
>>
>>>
>>>> However, many libraries may become incompatible with c++03 just by
>> virtue of
>>>> depending on another library that previously supported 03 but now
>> starts to
>>>> use c++11 features.
>>>
>>> 4. Drop this part entirely. If a library stops working in C++03 mode,
>>> it stops working. Users can contact the library maintainer and ask for
>>> them to support C++03. If Boost.X fails in C++03 mode because it
>>> depends on Boost.Y, the users don't need to care that the reason it
>>> fails is because of Boost.Y, their point of contact is Boost.X's
>>> library maintainer.
>>
>> I somehow felt this is important, but I don't remember why just now.
>>
>>>
>>>> Obviously, this change will only effect libraries that have supported
>> c++03
>>>> before. Libraries that already supported compilers and/or newer
>> language
>>>> versions are unaffected.
>>>
>>> 5. This seems obvious and not worth mentioning, but up to you.
>>
>> I also wasn't sure about that. I didn't want to give the impression
>> that from now on every boost library would start to support c++11
>>
>>>
>>>> If you want to continue to use boost in a project that has to stay
>> compatible with
>>>> c++03, recommendation is to stick to the last release before the switch
>>>> (probably 1.72).
>>>
>>> 6. Drop this part too. Users who want to be on latest Boost because
>>> they use Boost.X C++11+ library and Boost.Y C++03-compatible library
>>> should feel equally encouraged to do.
>>
>> Fine with me
>>
>>>
>>>> [add some more fluff?]
>>>
>>> 7. Same as #1. No fluff.
>>
>> OK
>>
>> Again, please someone else take the lead on the actual writing, as I won't
>> be able to work on this during the next week
>> or so (no access to a computer) a.
> 
> 
> *Nod.* I can do it. I volunteer Edward to help me.

I will be glad to help. But who is promising that once we write 
something up we will get any sort of consensus and that if we do it will 
actually be put on the website where it is easy to see ? In other words 
I do not think it will be that hard to complete a statement between us 
but if there is going to be no further action we will be wasting our time.

> 
> Glen

On Thu, Aug 30, 2018 at 7:03 AM Mike Dev via Boost wrote:

...

- The default language level for b2 builds will be at least c++11

Remove the reference to b2, it doesn't actually add anything. Say "The default language level for building Boost will be at least C++11".

(if the

...

compiler's default or the particular library doesn't specify a later version anyway)

That is not possible, on any build system, in a reliable way. As it involves enumerating every compiler build revision out there (including any custom ones) to determine what the compiler default is. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On 08/30/18 20:05, Peter Dimov via Boost wrote:

...

...

...

- The default language level for b2 builds will be at least c++11

That's going to be a bit complicated as we don't know in general what the default should be, but in any case C++11 is very rarely it. In fact using C++14 unconditionally will probably be better than trying to be clever.

+1. If we're going to drop C++03, we might as well require C++14 as the baseline.

On Thu, 30 Aug 2018, 19:27 Glen Fernandes via Boost, wrote:

On Thursday, August 30, 2018, Andrey Semashev wrote:

...

On 08/30/18 20:05, Peter Dimov wrote:

...

...

...

- The default language level for b2 builds will be at least c++11

That's going to be a bit complicated as we don't know in general what the default should be, but in any case C++11 is very rarely it. In fact using C++14 unconditionally will probably be better than trying to be clever.

+1. If we're going to drop C++03, we might as well require C++14 as the baseline.

+1. It also makes for a better sounding announcement.

+1. Yes, please. -- Mateusz Loskot, mateusz@loskot.net (Sent from mobile)

Andrey Semashev wrote:

On 08/30/18 20:05, Peter Dimov via Boost wrote:

...

...

...

...

- The default language level for b2 builds will be at least c++11

That's going to be a bit complicated as we don't know in general what the default should be, but in any case C++11 is very rarely it. In fact using C++14 unconditionally will probably be better than trying to be clever.

+1. If we're going to drop C++03, we might as well require C++14 as the baseline.

Wait, that's not what I meant. :-) I meant that we should build with cxxstd=14 by default because that's most likely going to match what other code is built with, not that we should require C++14. :-)

On 8/30/18 10:48 AM, Stefan Seefeld via Boost wrote:

(I seem to have the doubtful honour of writing the 100th message in this thread. That itself should ring an alarm bell...)

LOL - let's just drop the whole idea. Robert Ramey

Andrey Semashev wrote:

Seriously though, if C++14 is the default, why not announce it as the baseline?

Because this rules out g++ 4.8 (LTSes) and all presently existing versions of MSVC as supported compilers.

Mike Dev wrote:

g++-4.8 is out anyway, because it (or rather the standard library) doesn't have full c++11 support and Ubuntu 14.04 LTS will not be supported beyond mid-2019 (if that is what you meant by lts).

RHEL/CentOS 7 is supported until 30 June 2024.

IIRC, MSVC 2015 as pretty complete c++14 support.

Well... not really. Even C++11 constexpr doesn't quite work.

On Wed, 29 Aug 2018 at 05:29, James E. King III via Boost wrote:

On Tue, Aug 28, 2018 at 4:14 PM Edward Diener via Boost wrote:

...

Other than not removing useful Boost libraries which support c++03 as well as all subsequent C++ standard levels, and not telling people that they can not use such libraries in c++03 mode if they actually want to do so, I am perfectly willing to let others, including yourself, decide the best way in which support for c++03 in Boost is reduced. My argument has always been that putting a generalized statement on the website, without explaining what it actually entails as far as using Boost libraries is concerned, is going to lead to confusion and puzzlement from end-users and endless questions. What can it possibly cost to actually explain of what "Boost dropping support for c++03" actually consists, when it is finally decided what Boost is going to do in this area ? If it is a matter of correct grammar or exposition in the explanation, I will gladly volunteer to write it if no one else wants to do so.

I thought Peter Dimov got it right from the comment I saw earlier. The project would no longer spend time and effort on qualifying or testing C++03 compatibility. CI builds and the test matrix would no longer specifically test C++03. The default language level for b2 builds would be C++11.

Everyone says, amen! And, let's stop the thread there. And, let's get the C++11 mode in as prescribed above. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On Wed, 29 Aug 2018 at 10:12, degski wrote:

On Wed, 29 Aug 2018 at 10:28, Mateusz Loskot via Boost wrote:

...

Everyone says, amen! And, let's stop the thread there. And, let's get the C++11 mode in as prescribed above.

You better get busy programming then, pushing PR's, writing tests, update documentation and probably much more.

I'm not idling, neither in areas of Boost.

degski PS: if you could start with Boost.Multi-Array, I'd be most grateful, and possibly a number of other people as well.

If I start using it, I certainly might.

“If something cannot go on forever, it will stop" - Herbert Stein

Had Stein been aware of C++03. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On Tue, Aug 28, 2018 at 12:55 AM, Michael Caisse via Boost wrote:

On 8/27/18 15:39, Gavin Lambert via Boost wrote:

...

On 28/08/2018 05:59, Edward Diener wrote:

...

How many times do you think anyone compiles more than one TU with different cxxstd settings ? And how is this ever anything but a user error ?

Literally almost every Boost user on Linux does that (unless they compile Boost from source themselves).

I never do this. In fact, this is "doing it wrong". Software developers who do not build dependencies for their C++ programs and instead rely on package managers are "doing it wrong".

Not sure if serious.. Then how are C++ programs supposed to be packaged? -- Olaf

Note: I accidentally sent this message only to glen at first and am now mirroring it to the boost-ml

-----Original Message----- From: Glen Fernandes Sent: Monday, August 27, 2018 11:17 PM To: boost@lists.boost.org

On Mon, Aug 27, 2018 at 10:56 AM Mike Dev wrote:

...

Currently, many libraries are committed to support c++03, meaning they won't just start to use c++11 features [unconditionally] without prior announcement and some transition phase. After officially dropping c++03 support (with prior announcement and appropriate transition phase), whether a library happens to still compile with c++03 or not becomes an implementation detail that might or might not change with every new revision.

Do you have an example of a Boost library author or maintainer that has refused (either a pull request, or a other feature request) to leverage C++11+ features (after detecting them with Boost.Config, of course) to provide some more optimal implementation in their library, or provide a new feature their library?

There are Boost libraries are committed to supporting C++03, but they also leverage C++11, C++14, C++17 features when available, because this is what those particular library authors/maintainers are happy to do. (Myself included: I would not refuse to take advantage of a C++17 feature for C++17 users, while still supporting C++11 for C++11 users).

Conditionally using a c++11/14/17 feature is (usually) not the problem although there are sometimes pitfalls as Peter mentioned. However, it also has limited utility. E.g. it doesn't make sense to simplify a function implementation using c++11 features like auto, range based for, decltype, constexpr instead of TMP, if you have to maintain the c++03 code path as well. In principle, you could conditionally get rid of some boost dependencies in c++11 mode, but again at the cost of maintaining two different code paths (as boost types often have slightly different semantics from c++11). So why do it? And you still can't deprecate the dependency itself because it is still needed in c++03 mode. So except for cases with a very high value proposition (move semantics, simplified api, c++11 only functionality) or simple annotations (noexcept, override) using c++11 features *conditionally* is usually not all that beneficial. My hope here is that at some point, those boost libraries will finally start to use c++11 features *unconditionally* in order to simplify things - not add even more complexity in the form of conditional compilation. Best Michael

On 8/27/2018 10:56 AM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Monday, August 27, 2018 6:21 AM

You are correct in that I do not understand why making an announcement that Boost is "dropping support for C++03" is going to make any difference to anybody, when nothing further changes as far as Boost is concerned and in fact some Boost libraries continue to support C++03 simply because they do not require C++11 on up features.

Happy to quote myself again

================

You as a library programmer should know better than anyone else that there is a difference between supported (and hopefully) documented API behavior, which you are committed to support and implementation details that might change at any moment (and don't get me started on UB that happens to do what you expect in a particular version of your compiler).

Currently, many libraries are committed to support c++03, meaning they won't just start to use c++11 features [unconditionally] without prior announcement and some transition phase. After officially dropping c++03 support (with prior announcement and appropriate transition phase), whether a library happens to still compile with c++03 or not becomes an implementation detail that might or might not change with every new revision.

So you are saying that if Boost announces that we are "dropping support for C++03" that a library which today does support C++03 and tomorrow does not support C++03 should not need to wait to do so ? I would say that end-users would not understand this as "dropping support for C++03" unless it were explained to them as part of what it meant.

================

Now, disagreeing with or not understanding my arguments is one thing, but the fact that you keep completely ignoring what I'm saying or even worse insinuating that I would suggest things when I actually stated the exact opposite makes me wonder if you try to have a discussion with me or rather just reflexively answer to anything that contains "drop support for C++03" with some default statements of yours, because I'm just the next guy suggesting to "drop c++03 support".

...

And if something further is actually supposed to change regarding Boost other than making such an announcement, I would love to hear about what it is from you. I do not believe in doing something for no particular reason just because someone thinks it sounds 'good'.

...

I am also curious about what documentation is supposed to be changing when you say "changing the documentation".

If I seem belligerent it is because you are only the last of a stream of people saying that Boost should "drop support for C++03" without saying what in particular this is supposed to entail, other than Boost supposedly announcing that this will be the case.

That is the point: It is not supposed to entail anything more than that.

Try to put yourself in the place of end-users who are not involved in this mailing list. If Boost announced on their website that they are "dropping support for C++03" could you not realize that without a detailed technical explanation of what this is supposed to mean that the end-user would have no idea what such a message actually is about. This is the crux of why I have been trying to get you to say what this actually means at least to you, rather than it being just verbiage. If it is just an announcement, without any further technical changes to Boost, why say it in the first place. It will just serve to confuse people and not just me.

Now, there are a lot of things I *would like to do* if support for c++03 is dropped on a boost wide level, such as - Deprecating libraries and types that have been merged into the standard (why spend the effort of maintaining them). - Removing internal dependencies when they can be replaced with c++11 standard library or language constructs - Remove conditional compilation paths - Reduce test matrix (removing all compilers that can't compile in c++11 mode and making sure every test is compiled with at least c++11) - Migrate libraries from mpl to mp11 - Simplify some code paths where possible. A library might not require c++11 features, but almost any library I've seen can profit from c++11. (some of those changes I actually have already done in private forks of boost libs)

But regardless of what is discussed and/or decided on the ml, none of the library maintainers could be forced to accept any of those changes anyway so I don't see the point of discussing those here. I'd rather discuss specific changes with the responsible maintainer in an issue/PR at the respective github repository.

However, officially dropping c++03 support (boost wide) would get rid of problems like this this:

"Oh I'd like to apply that change to library A, but that requires at least c++11 and the boost libraries X,Y,Z depend on A compiling in c++03 mode, so I can't do it without announcing the switch on the ml and then wait for a year or so until they have found an alternative - so sorry, but that's just not worth it"

because if your library is not officially supporting c++03, no one should rely on that anyway regardless of whether it works at the moment or not and if they do rely on it anyway, it is their problem. (see my above argument about supported API behavior vs implementation details)

I understand you. But a statement that "Boost is dropping support for C++03" will not directly translate in someone's mind to what you have just suggested above. It does in your mind because that is your interpretation of what it means. I would suggest that the statement that "Boost is dropping support for C++03" will much more likely translate directly in most people's minds to "I can no longer use the C++03 standard level of compilation when I work with any Boost library". Since that is not intended to be the case, even for those who would like to see Boost deprecate support for C++03 compilation, I would suggest that a Boost announcement of "dropping support for C++03" is not apropos and a more specific announcement vis-a-vis C++03 when using Boost would be more apropos.

...

I am also curious about what documentation is supposed to be changing when you say "changing the documentation".

I think you started mentioning changing the documentation first, but either way, what I'd expect is a note *along the lines of*:

"This library is supporting compilers x, y, z and supports c++11 and upwards language standards. Compilation with an older compiler or in c++03 mode may be possible, but is not supported any may break with any new release without prior notice."

I have in the past highly encouraged library developers/maintainers to specifically include in the documentation to their libraries the level of C++ standard support that is needed to use their library. I personally think that information should be front and center in the introduction to every library, even if I have been perhaps as remiss as anyone else in providing it.

@degski Personally, I'm much more interested in code simplification and reduction of dependencies than (run-time) speed improvements, but of course others have different priorities.

Best

Mike

-----Original Message----- From: Boost On Behalf Of Edward Diener via Boost Sent: Sunday, August 26, 2018 7:07 AM

On 8/25/2018 1:51 PM, Mike Dev via Boost wrote:

...

From the discussion about abi compatibility when the Boost.System library is compiled e.g. in c++03 mode and then included in a c++11 project or vice versa (https://groups.google.com/forum/#!topic/boost-developers- archive/EWG5NVOZo_ g)

...

When can we drop C++03 support? :D

[...]

What about the first or second release in 2020 ?

Please define what is meant by "dropping C++03 support

For me it means that - a contributor can use c++11 language and library features (be it the library maintainer or someone else opening a PR on Github) - A user (external or internal) may no longer expect a boost library to compile with a compiler not supporting c++11 (and we can have a discussion just which compilers that are) or when he tries to compile it in c++03 language mode (e.g. -std=c++03) Is that definition precise enough? What other definition did you have in mind (if any)? If that is your concern: I would certainly not expect that you start ripping out the guts of an old, battle proven library and replace everything with c++11 features just for the fun of it. However, next time a feature is added or a bug has to be fixed, you no longer have to restrict yourself to c++03. And maybe, over time, some people will contribute patches that simplify / improve a library by replacing some complex c++03 solutions with simpler c++11 solutions when applicable. Best Mike

Edward Diener wrote:

My objection to the usual Boost "dropping C++03 support" is that there is absolutely no reason for forcing libraries which do support C++03, while being usable at any higher C++ standard level, to do anything.

Boost dropping C++03 support means just that, we announce that Boost no longer supports C++03. Individual libraries may or may not continue to support it, but f.ex. trying "b2 install" with a C++03 compiler will no longer be expected to work. We could then consider building with -std=c++11 by default on g++ 4.8/4.9, and with -std=c++14 by default on g++5 and possibly clang (although clang c++14 doesn't quite work with libstdc++ 4.x so that'd be a problem).

On 08/26/18 15:46, Peter Dimov via Boost wrote:

Tim Blechmann wrote:

...

...

By then, all major toolchains have had solid c++11 support for at least > 5 years ( I think, msvc was the last one with VS2015) and at least > partial support for 7+ years (gcc 4.8, msvc 2013, clang 3.3).

compilers are one thing, compiler adoption is another ... i remember that in the past "stable" linux distributions provided compilers that were considered as "outdated", but that were used in production on HPC systems. but maybe this is less of an issue these days ..

The current LTSes (Ubuntu Trusty, CentOS 7) are on g++ 4.8, which has reasonable (but not quite complete) C++11 support.

The current Ubuntu LTS is 18.04 (Bionic), it ships with gcc 7.3 and clang 6.0.0. 16.04 (Xenial) and 14.04 (Trusty) are stull supported, though - until 2021 and 2019, respectively. https://wiki.ubuntu.com/Releases

On 08/26/18 18:26, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

...

The current LTSes (Ubuntu Trusty, CentOS 7) are on g++ 4.8, which has > reasonable (but not quite complete) C++11 support.

The current Ubuntu LTS is 18.04 (Bionic), it ships with gcc 7.3 and clang 6.0.0. 16.04 (Xenial) and 14.04 (Trusty) are stull supported, though - until 2021 and 2019, respectively.

That's what I meant by "current" - still supported. As I've said before, you don't use an LTS if you keep upgrading at earliest opportunity.

Well, apparently our understanding of "current" is not the same. :) There are many reasons to upgrade to the latest LTS release when it comes out, and many people do.

Mike Dev wrote:

- I'm not sure what counts as EOL for RHEL/CentOS (that might be the problematic one), but the way I read the matrix in (https://access.redhat.com/support/policy/updates/errata), the oldest relevant distribution in 2020 (although already in Extended Life-cycle Support) will be RHEL 6 which only shipped with gcc4.4.

CentOS say in https://wiki.centos.org/Download that 6 is supported as "Production Phase 3" which they therefore don't recommend using. "The CentOS team recommends that you start moving workloads from CentOS Linux 6 to CentOS Linux 7."

Tom Kent wrote:

To confuse the problem even more, just like other compilers, there is no version that can easily be pointed to as having full C++11 compatibility. 2015 is probably the closest, but still has a few missing features: https://msdn.microsoft.com/en-us/library/hh567368.aspx

Actually, just one "Expression SFINAE".

However, for some uses even VS2010 might have sufficient C++11 support...if all you need is auto and shared_ptr.

2013 is, well, good enough for mp11. Pre-2013, no variadic templates, hard to call it C++11. 2013 doesn't have noexcept though.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Tom Kent via Boost Sent: 27 August 2018 22:50 To: Boost Developers List Cc: Tom Kent Subject: Re: [boost] A possible date for dropping c++03 support

TL;DR - We need to be more supportive of end-users needs, they're the (silent) majority - Publicize with the 1.69 release, that libs can drop C++03 support at any time - Support future 1.68.X releases if security issues (only!, no bugfixes) are ever discovered

All that said, (with my C++ fan hat on) I don't want to hold back boost growth by keeping it saddled with crucial libraries that are stuck in C++03 mode...and fully support new libraries being C++11/14/17/2a only. I think that from the next release forward, we should make it clear in the release notes that existing libraries may be dropping C++03 support at any time without advanced notice (although it would be nice if some of the core libraries gave specific notice of this 1+ releases early, so it can filter down through libraries that may depend on them). This will let users know that they need to be extra careful with updates if they are still C++03.

Additionally, it would be good to publicize that the 1.68 release will be the last release with broad C++03 support (minus libraries that never supported it). So it is clear for non-c++11 projects which version they should choose. Additionally, if we encounter security vulnerabilities going forward, I think it would be good that we be able to roll future versions of this "last" C++03 release e.g. 1.68.1. To my knowledge we've never had a minor release to a previous version after the next version (e.g. 1.69) was released, so this would be a new thing....and may require some (minor?) changes to the release tools. This should be for true security fixes only, no backporting bug fixes!

+1 1 Publicize with the 1.69 release, that libs can drop C++03 support at any time.(even though this is old news). 2 Support future 1.68.X releases if security issues (only!, no bugfixes) are ever discovered and 3 Publicize that increasingly libraries will be requiring C++14 and 17, and some are *already* requiring as-yet-unstandardized C++2Z! So plan to keep up. 4 A last release version of C++11, 14, 17 ...will be announced a version(or two) ahead. Or do anything - if only to stop this endless argument to little purpose ;-) Paul