Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?

Subject: Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-11-05 12:26:13

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Cromwell Enage via Boost
> Sent: 03 November 2018 02:18
> To: boost_at_[hidden]
> Cc: Cromwell Enage
> Subject: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
> 
> Hi, everyone.
> 
> The end of section 3.2.1 of the current Boost.Parameter home page tutorial
> notes "that because of the forwarding problem,
> parameter::parameters::operator() can't accept non-const rvalues".  I've
> submitted a PR to the develop branch on GitHub that would grant
> Boost.Parameter the ability to support perfect forwarding and eliminate
> this issue.  However, the PR uses rvalue references (in parameter::keyword,
> parameter::parameters, and the code generation macros) and variadic
> templates (in parameter::parameters and the code generation macros).  With
> the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make
> Boost.Parameter a C++11 library.  As a result--based on <
> http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-dependencies>--the
> following Boost libraries known to use Boost.Parameter would also become
> C++11:
> 
> Boost.Accumulators
> Boost.Convert
> Boost.Graph
> Boost.Heap
> Boost.Log
> Boost.MetaStateMachine or Boost.MSM
> Boost.Parameter_Python
> Boost.Signals2
> 
> I'd like to hear from everyone else, especially the maintainers and users
> of these libraries, if it's okay for Boost.Parameter to go C++11 and above
> only or if C++03 support is still necessary.

My view is that it is up to you to decide (but asking for views is good too).

If it is not too difficult to make it continue to be C++03 compatible and yet allow C++11 (or higher) improvements then you should
do this.

For example, if you can easily write

#ifdef BOOST_NO_C11_feature

  do the current C++03 stuff (even full function definition)

#else

  do the enhanced version

#endif

then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it

 "We should try to eliminate things that unnecessarily piss people off,"

(See https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-nice-to-customers-idUSBRE98J0DF20130920 for sordid
details)

but if this proves difficult (and trying it may be the only way to find out) then you should announce that it will require some
C++11 feature one release ahead of the change.

You should change the jamfile to require the new C++11 feature(s) as this demo

https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/build_config.html

This will leave a blank in the regression matrix for those platforms that don't support this C++11 feature
that will flag to users that it won't work and they need to freeze their Boost at this version, or get a more  up-to-date compiler.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]