On 5/24/2020 8:38 PM, Edward Diener via Boost wrote:
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.
This is my error. The MPL library does use Boost type_traits where there is an equivalent C++ standard type_traits. So I concur that use of MPL would place a Boost library like TTI below the C11 Epoch.