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