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.