Re: RFC: Deprecate libstdc++ Policy-Based Data Structures

[Tadeus Prastowo <tadeus dot prastowo at unitn dot it>]

On Wed, Jul 24, 2019 at 1:01 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 24 Jul 2019 at 11:52, Tadeus Prastowo <tadeus.prastowo@unitn.it> wrote:
> >
> > On Wed, Jul 24, 2019 at 12:40 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > >
> > > [Removing gcc@gcc.gnu.org from the CC list]
> > >
> > > On Wed, 24 Jul 2019 at 10:11, Tadeus Prastowo <tadeus.prastowo@unitn.it> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Knowing that Alex has stepped forward, I am interested in helping out
> > > > in this matter as well if you think that will help.  My experience in
> > > > maintaining a C++ library can be seen at
> > > > https://savannah.nongnu.org/projects/tice
> > >
> > > Would you be any more or less willing to help if the code lived in a
> > > separate repository, either on sourceware.org or savannah.gnu.org?
> >
> > I would be less interested because then the library is just another
> > C++ library out there.  In particular, if the library is no longer
> > part of libstdc++, maintenance and deployment would be harder because
> > the library is no longer compiled, tested, and deployed as it is now;
> > marketing would also suffer.  In other words, being part of libstdc++,
> > the library receives additional contributions from GCC maintainers as
> > well as marketing channels.
>
> But it doesn't.

I think it does for marketing channels as the PBDS is available
automatically whenever libstdc++ (that is, g++) is installed.

The library also indirectly receives additional contributions from GCC
maintainers through the compile-testing-deploy cycle of GCC.

> It's bit-rotting and nobody knows about it.

At least Alex and his community know it.  As for the bit-rotting, Alex
has stepped forward as its user to maintain it.  I can help him with
the technical stuff by proposing myself to be a co-maintainer.  Alex
and his community then can provide the needed tests and criticisms
(well, bug reports) from the user's point of view.  But, being part of
the libstdc++ will provide the needed feedback from the technical
point of view through GCC compile-test-deploy cycle (e.g., ABI
compatibility, deployment on different machines).

> > > I'm not trying to delete all the code, I'm trying to move it out of libstdc++.
> >
> > And, being part of libstdc++ really means something.
>
> In this case it means we're expected to carry around all this code for
> questionable benefit.

Alex says that it has some benefits, and he has proposed to maintain
it.  I propose to co-maintain it since I also see that it has some
merits now that I have read its online documentation to understand why
it is called "policy-based" and Alex and his community use it.

-- 
Best regards,
Tadeus