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

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-09-24 10:36:10

On 9/24/2020 4:59 AM, Paul A Bristow via Boost wrote:
> 
> 
>> -----Original Message-----
>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Gavin Lambert via Boost
>> Sent: 24 September 2020 03:57
>> To: boost_at_[hidden]
>> Cc: Gavin Lambert <boost_at_[hidden]>
>> Subject: Re: [boost] Proposal for adding C++ level to the meta/libraries.json
>>
>> On 23/09/2020 23:15, Rainer Deyke wrote:
>>> I'm actually very interested in when a library is rendered obsolete by
>>> a
>>> C++ standard.  Lots of Boost libraries have equivalents in the C++
>>> standard library, or in some cases in the language itself.  In some
>>> cases, the standard library component has completely rendered the
>>> Boost version obsolete.  In some cases, the Boost version only exists
>>> as a backport of the standard library component, and was never
>>> intended to be used in C++ versions that include that component.  In
>>> some cases, the Boost version and the standard library component have
>>> developed in different directions, and both are viable.  And in some
>>> cases, the Boost version exists to correct a perceived flaw in a
>>> standard library component, so the Boost version should probably be
>>> preferred.  It is often not clear which of these applies to which
>>> library, even after reading the library documentation (which may
>>> predate the standard library component).
>>
>> In theory, I think that's what the existing "std" field was for: "this library is included in this standard
>> version".
>>
>> Although that's not the whole story, since e.g. Boost.Assign as you mentioned was not directly included
>> but (AFAIK) is rendered entirely obsolete by initializer lists, and e.g. Boost.SmartPtr and Boost.Thread
>> while *mostly* obsolete do include some extended functionality not in the standard implementation.
>>
>> And Boost.Variant[2] make different design choices from the standard implementation, so all three are
>> viable alternatives.
>>
>> I don't think any meta field is really going to capture these sorts of things too well.
> 
> But better than nothing?
> 
> Provided we don't oversell the information.  We need some BIG cautions that this is only a very approximate guide to the full story - which is ultimately "try it and see".

My disgust with the "try it and see" approach is the main reason why I 
proposed the additions to the meta information, which would, at the very 
least, tell the end-user whether a Boost library is compilable for the 
C++ standard level they are using. Is this really too much information 
to give end-users, and is it really better that an end-user should have 
to dig through Boost library docs, where the information is often not 
there at all even if it could be found, just to find out if Boost 
library X can be compiled by the end-user who is using C++ standard 
level Y for his project ? I doubt it. Yes, a given library might be more 
complicated, and provide some functionality over and above the minimal 
C++ standard level needed to use that library depending on a host of 
features in the compiler being used, but that is no reason to not at 
least tell the end-user what the minimum level needed actually is, and 
then the end-user can read the docs and hopefully find out what other 
"advanced" library features, needing what other C++ standard level 
features, are available for that library. But that does not negate the 
fact that simply using the basic features of a Boost library the 
end-user would like to know if his C++ standard compilation level is 
good enough for X library's main functionality.