Re: Proposal for adding C++ level to the meta/libraries.json

From: pbristow_at_[hidden]
Date: 2020-09-22 17:04:01

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Edward Diener via Boost
> Sent: 22 September 2020 17:03
> To: boost_at_[hidden]
> Cc: Edward Diener <eldiener_at_[hidden]>
> Subject: Re: [boost] Proposal for adding C++ level to the meta/libraries.json
> 
> On 9/22/2020 4:42 AM, Paul A Bristow via Boost wrote:
> >
> >
> >> -----Original Message-----
> >> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Edward
> >> Diener via Boost
> >> Sent: 21 September 2020 18:37
> >> To: boost_at_[hidden]
> >> Cc: Edward Diener <eldiener_at_[hidden]>
> >> Subject: [boost] Proposal for adding C++ level to the
> >> meta/libraries.json
> >>
> >> Since we are reviewing Vinnie Falco's JSON library I thought that
> >> this would be a good time to present a proposal to add information to
> >> each Boost library's meta/libraries.json file regarding the level of
> >> C++ standard compliance for that library. This could then be added to
> >> each library's visual documentation so that end-users would instantly know the C++ standard level
> they would need to use in order to use a Boost library.
> >>
> >> My proposal is to add 3 fields whose data would be the same as the
> >> cxxstd allowed values from Boost Build, using the first value of each choice ( currently 03, 11, 14, 17,
> 20 ).
> >>
> >> standard = minimum C++ level for the library extended = same
> >> functionality in the library as the minimum C++ level but with
> >> extended use given higher C++ levels required = new functionality in
> >> the library above the minimum C++ level which requires given higher
> >> C++ levels
> >>
> >> The 'standard' field would be a single value, while the 'extended' or
> >> 'required' fields could be more than one comma separated value. If
> >> you don't like the names for 'standard', 'extended', or 'required' you can bikeshed the name,
> although I think the 'standard' name is pretty well apparent.
> >>
> >> The idea is to provide this information in the meta/libraries.json
> >> field for each library, so that the end- user of the library can
> >> immediately know the usability of the library with appropriate C++ standard levels of compilation.
> >>
> >> I realize that the line between the 'extended' and 'required'
> >> entries, as I have described them, could be blurred. The 'standard'
> >> field remains the most important. I have long felt that the end-user
> >> should not have to do any investigation, in code or in documentation,
> >> just to determine if a library is usable for his
> >> C++ standard level of compilation.
> >
> > I've been muttering about this tricky issue for some time.
> >
> > For a big and old and still growing library like Boost.Math, the problem is even more difficult.
> >
> > For many math functions and distributions, C++03 (with C++11 numeric_limits) is fine, but as one
> starts to use newer items, then requirement shift up to needing C++20.
> >
> > We have recently decided to require a minimum C++11, but that still means that users may find that
> some components need more.
> >
> > Predicting the requirements for certain is difficult -  I fear in
> > practice, it means 'sucking and seeing' ☹
> >
> > I have suggested marking each header file with its minimum requirements, but that is messy and
> doesn't really help the user much.
> >
> > My ideal is to say 'always use the latest compiler version and highest
> > standard level', but that isn't popular 😉
> >
> > But it is a reason to encourage users to plan to keep updating all their tools - and keep their
> management on-board with that concept.
> >
> > So I support Edward's proposal, but caution that it isn't as helpful for some libraries as others.
> 
> You could tag Math as:
> 
> standard : 11
> required : 14, 17, 20
> 
> It least that tells end-users that C++11 is the minimum level but that some functionality will need C++14,
> C++17, or C++20. I think that information is very helpful to end-users. Nothing is perfect but let's settle
> for what is at least good and helpful.

OK - I'm happy with that - but it isn't a big help for some libraries.

> > The bottom line is always going to be: "If it works for your configuration, fine - otherwise bad luck."

Paul