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