-----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. In any case, what "further clarification" would you like to see? I mean, so far, there is neither the text for the announcement, nor for the documentation of XX. If there is general agreement that all this is a good Idea (and at the moment I'm not sure there is), we can certainly start bike shedding over the exact wording of both.
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.
Just to be clear here: I do hope and expect that at least some libraries will start to use c++11 feature unconditionally as soon as the switch is made in 2020 (or at least 1-2 releases after that). If there isn't at least some interest from the side of the affected maintainers, my suggestion will certainly not be accepted anyway (i.e. not generate the necessary momentum be implemented). Now, due to the tight coupling between the libraries (in particular the older c++03 compatible ones) this will effectively make a lot of other libraries c++11 too. However, as no one can or should force a library maintainer to use c++11 code in his library, all I'm trying to achieve here is to lower the bar for the unconditional introduction of c++11 as much as possible for the authors that want to do this. In particular, the obstacles I try to address here are - concern for "breaking" users - in particular fellow boost libraries in c++03 mode. - The necessary transition period between "yes, I would like to make this change (which would require c++11)" and when it can actually be implemented