Re: [epochs] Proposal for an epoch-based organization of Boost libraries

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-05-25 00:38:41

On 5/24/2020 4:15 PM, Joaquin M López Muñoz via Boost wrote:
> TL;DR: we basically agree on the same tenets, but there's been some mutual
> misunderstanding around during our conversation.
> 
> El 24/05/2020 a las 20:02, Edward Diener via Boost escribió:
>> On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:
>>>
>>> I'm not sure I'm parsing your sentences right, but does that mean 
>>> you're ok
>>> with a library using cxx_dual from scracth but not ok if a 
>>> Boost-reliant lib is
>>> later updated via cxx_dual *only* to reduce Boost dependencies in C++11?
>>
>> No.
>>
>> I am ok with a library changing itself to use C++ standard libraries 
>> instead of their Boost
>> equivalents in any way it wants, whether using cxx-dual, whether 
>> creating its own
>> interfaces for both Boost and the C++ standard equivalent, or whether 
>> just switching
>> from using Boost to the C++ standard equivalent. But I am aware that 
>> such a change
>> takes work, [...]
> 
> 
> This work is up to authors: if they are ok with not being given the shiny
> epoch badge, they can continue with the status quo.
> 
> 
>> and will displease some end-users. 
> 
> 
> I fail to see in which situations users would be displeased by internal 
> dependencies
> being reduced.
> 
> 
>> If the Epoch proposal is merely to get a given Boost library to create 
>> another version
>> of itself where it uses C++ standard libraries instead of Boost 
>> libraries so it can be part
>> of a later Epoch I can see the value of your proposal, but again who 
>> will do the work
>> of this transformation ? 
> 
> 
> Answered above.
> 
> 
>> But if the Epoch proposal entails forcing a given library to use some 
>> features of
>> a C++ standard so that it can be part of an Epoch [...]
> 
> 
> The proposal does not entail that.
> 
> 
>> If we are just talking about library dependencies, then a Boost 
>> library which has
>> 0 or more dependencies on only C++ standard libraries of a given Epoch 
>> belonging
>> to that Epoch is actually fine with me. But this of course means that 
>> a Boost library
>> which has no dependencies on either Boost libraries or their C++ 
>> standard equivalent
>> libraries of a given Epoch belongs to all Epochs, which is the way it 
>> should be IMO.
>> So Boost PP, as an example, belongs to all Epochs.
> 
> 
> Well, yes, exactly, Boost.PP belongs to all epochs. Another example 
> (mentioned in
> the proposal) is Boost.Mp11: no internal dependencies, requires C++11, 
> not subsumed
> by the standard yet --> it belongs to all epochs from Boost11 to 
> Boost20. "Requires C++11"
> implies "works in C++N" for N>=11.
> 
> 
>>>> The gist of your proposal which seems to me to be highly flawed is 
>>>> the idea
>>>> that at a certain Epoch level all dependencies of a library must 
>>>> also exist at that
>>>> same Epoch level or higher. How realistic is such a goal ? If 
>>>> library X at Epoch level nnn
>>>> successfully uses library Y at Epoch level nnn-1, why should library 
>>>> Y be arbitrarily updated
>>>> [...]
>>>
>>>
>>> I understand you meant "should library X be arbitrarily updated" here.
>>
>> No, I meant that library Y should not be arbitrarily updated so that 
>> library X can be
>> considered valid for Epoch nnn. The only case I see where library Y 
>> would need to be
>> updated, with perhaps another version at Epoch level nnn, would be if 
>> library Y had
>> a dependency on a Boost library where an equivalent C++ standard 
>> library which works
>> at Epoch level nnn was available.
> 
> 
> I understand your reasoning now and don't think there's more to discuss 
> about it
> now we've clarified that belonging in BoostN implies belonging  in 
> BoostM (M>N) so
> long as the lib is not subsumed by the standard. (To be precise, there's 
> also rejection
> rule 2, which denies promotion when a new library subsumes the old, case 
> in point
> MPL and Mp11).
> 
> 
>>>> [...]for no good practical reason to use C++ features of Epoch level 
>>>> nnn ?
>>>>
>>>
>>> The reason is to reduce internal Boost dependencies.
>>
>> Adding C++ features at a certain C++ level rarely has to do with 
>> dependencies as
>> opposed to the necessities of programming design. If adding a feature 
>> at a certain
>> C++ level was able to reduce a dependency of a library to another 
>> library I would
>> in general be all for it. 
> 
> 
> The proposal says nothing about adding features to be granted epoch 
> promotion.
> 
> 
>> But just let's take a library that is designed in such a way that it 
>> does not need
>> any features of, let's say, C++11. Why would anybody want to add some 
>> feature
>> just for the sake of saying that the library is at Epoch 11, when such 
>> a feature
>> is unnecessary in the design of the library. This is what I mean by 
>> "absurdity".
> 
> 
> I agree this is absurd. This is not what the proposal says.
> 
> 
>>> [...]
>>>
>>> Take for instance Boost.Beast, which depends on boost::string_view 
>>> but can
>>> be made to depend on std::string_view instead via 
>>> BOOST_BEAST_USE_STD_STRING_VIEW.
>>> Shall I take that you deem this ability absurd?
>>
>> Not at all. But take a library which works fine at the C++03 on up 
>> level, such as TTI,
>> and has no dependencies on other Boost libraries which can be dropped 
>> by adding
>> some arbitrary feature of C++ 11 on up. Why should not this library be 
>> used by an Epoch
>> library at the C++11 level if its usefulness is apparent to that Epoch 
>> library. And why
>> disqualify that Epoch library from its level just because TTI does not 
>> use C++11 features.
> 
> 
> I think the terms of promotion/rejection have been discussed in enough 
> detail above.
> As for the particular case of Boost.TTI, it wouldn't enter into Boost11 
> because it uses
> Boost.MPL, which is subsumed by Boost.Mp11 in C++11.

The MPL library uses no Boost library where a C++11 on up standard 
library is available. So your "Boost.MPL, which is subsumed by 
Boost.Mp11 in C++11" does not make sense to me. While MP11 may be a C+11 
library that is worthy to use, I see nothing wrong with a C++11 on up 
library using MPL as far as dependencies go.