Re: [boost] A possible date for dropping c++03 support

Subject: Re: [boost] A possible date for dropping c++03 support
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2018-08-30 18:25:59

On Thursday, August 30, 2018, Mike Dev via Boost <boost_at_[hidden]>
wrote:

> > -----Original Message-----
> > From: Boost <boost-bounces_at_[hidden]> 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.

Glen