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

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2020-05-24 20:15:16

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. If you want to get 
the badge
(if you don't then there's nothing else to do) then you'd have to 
conditionally use Mp11
or directly migrate to Mp11 and drop C++03 support. There's three 
options here, and
the proposal does not mandate any, although authors are expected to 
aspire to
newer epochs (that's the "incentivation" part).

> The gist of our disagreement is that I can see the usefulness of your 
> proposal regarding
> Boost dependencies versus C++ standard equivalents, but not regarding the
> arbitrary distinction of whether some library uses some C++ feature of 
> some C++ standard level.

No disagreement here. The rules for membership in BoostN are:

/"A Boost library //*X*////belongs//to epoch //*BoostN*//if: /

  * /*X*//is compatible with C++//*N*//,/
  * /*(rejection rule 1)*//the functionality provided by //*X*//is not
    already covered by C++//*N*//,/
  * /*(rejection rule 2)*//the functionality provided by //*X*//is not
    superseded by some other, more modern, library //*Y*//in //*BoostN*//,/
  * /all the libraries in depN(//*X*//) belong to //*BoostN*//."/

"X is compatible with C++N" does not mean "X uses new features/libraries 
introduced in C++11".

> I would agree wholeheartedly with the idea that for any given Boost 
> library, X, at no matter
> what C++ standard level, which uses 1 or more other Boost libraries 
> when a C++ standard
> equivalent is available at some C++ standard level, that it would be 
> advantageous for
> end-users to have another version of that library which uses the C++ 
> standard equivalents.
> But doing such work is hardly trivial.

Already discussed above, I think.

Now that I think we are on the same page regarding what the proposal is 
and is not about, I'd
like to ask you if you found some particular section on the proposal 
text misleading:
I can try and make it more clear.

Joaquín M López Muñoz