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

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-05-24 18:02:25

On 5/24/2020 12:38 PM, Joaquin M López Muñoz via Boost wrote:
> El 24/05/2020 a las 14:52, Edward Diener via Boost escribió:
>> On 5/24/2020 4:20 AM, Joaquin M López Muñoz via Boost wrote:
>>> El 23/05/2020 a las 22:46, Edward Diener via Boost escribió:
>>>
>>>> I am totally against the idea that some code which works perfectly 
>>>> in C++03, as well as all
>>>> other C++ standard levels, needs to be unnecessarily updated to some 
>>>> later C++ standard
>>>> level in order to be acceptable to anyone. 
>>>
>>> This looks somewhat at odds with one of the stated goals of your 
>>> cxx_dual lib:
>>>
>>> "On a more practical basis the CXXD library is for:
>>>
>>> 1. Programmers writing code not using C++11 syntax who still want to
>>> Â Â Â  target some
>>> Â Â Â  C++11 libraries if the code is compiled in C++11 mode.
>>> Â Â Â  [...]"
>>
>> I do not see why you think the statement above is at odds with what I 
>> previously
>> asserted. Whatever might have been added to a Boost library which 
>> became a
>> C++ standard library in C+11 or beyond could hardly have been done 
>> just to add
>> unnecessary features. I am not against a library being updated to use 
>> features of
>> a later C++ standard when those updates are predicated on improving a 
>> library
>> in specific ways that make it worthwhile to add such features.
>>
> 
> 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, 
and will displease some end-users. 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, I see that is a failure of conception.

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.

> 
> 
>> 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.

> 
> 
>> [...]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. 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 am pretty sure you can see the absurdity of such a determination as 
>> that. 
> 
> 
> I admire your confidence but not your perspicacity, as I indeed see no 
> absurdity here.
> 
> 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.

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.

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.