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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2020-09-22 10:22:01

Am 22.09.20 um 10:42 schrieb Paul A Bristow via Boost:
>> -----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.

TBH I didn't understand the meaning of "extended" and "required" as I 
failed to parse the sentence. Might be my English though.
How about:
- minimum required C++ standard version to use this library
- maximum C++ standard version which adds new features (i.e. for Math 
that would be C++20, although for most libs it would be the same as above)
- opt.: Superseded by which C++ standard version (this came up in the 
"deprecate C++03" discussions): When a library has been fully (or 
mostly) absorbed by a standard that might be valuable to tell)

I think the first is unquestionable and easiest. The latter 2 are 
optional and could be harder to specify and keep up to date. But at 
least there is a clear distinction what is what