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?
> 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
> 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 ?
> 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
> 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
the proposal) is Boost.Mp11: no internal dependencies, requires C++11,
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
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
rule 2, which denies promotion when a new library subsumes the old, case
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
> 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
> 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
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
>> 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
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
(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
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
I can try and make it more clear.
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk