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

From: degski (degski_at_[hidden])
Date: 2020-05-23 16:31:42

On Sat, 23 May 2020 at 11:21, Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> On 2020-05-23 19:15, degski via Boost wrote:
> > On Sat, 23 May 2020 at 06:25, Andrey Semashev via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> Next, I disagree with the idea that a library could be "not allowed to
> >> progress". Why block further improvements and extensions? Take
> >> Boost.Atomic or Boost.FileSystem, for example. These libraries are not
> >> equivalent to the standard counterparts, and offer extensions that are
> >> useful in practice and cannot be efficiently implemented "on top" of the
> >> standard components. What would be the point of a Boost.Atomic v2 if it
> >> had to reimplement Boost.Atomic? We are spreading our time thin as it is
> >> already.
> >>
> >
> > The progression could be signified by another 'insertion mode' :
> increases
> > begin(*X*) and executes end(*X*) = begin (*X*) +1.
>
> I'm not sure what you mean here.
>

Like in the proposal [in this idea] the library is frozen (kicked out), but
really not, the improvements that come after the frozen epoch are included
in an annual 'update', of that years epoch. So you can (should be able to)
keep on choosing between the boost and the std version on an epoch basis.
One can express this idea by begin(*X*) and executes end(*X*) = begin (*X*)
+1, as I suspect this rule will be implemented.

That was the gist of it.

degski
-- 
@systemdeg
"We value your privacy, click here!" Sod off! - degski
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding
"Growth for the sake of growth is the ideology of the cancer cell" - Edward
P. Abbey