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

Subject: [boost] A possible date for dropping c++03 support
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-08-27 14:56:35

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