RFC: Deprecate libstdc++ Policy-Based Data Structures

[Jonathan Wakely]

On Wed, 24 Jul 2019 at 12:40, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 24 Jul 2019 at 12:36, Tadeus Prastowo <tadeus.prastowo@unitn.it> wrote:
> >
> > 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.
>
> OK, since you two are willing to help I will drop my suggestion to
> deprecate it - thanks!
>
> Please feel free to ask any questions here on this mailing list, or
> reach out to me directly (but preferably on the mailing list as there
> are others who can help you here too).

It's been six years and nobody has contributed a single fix to the
pb_ds code (except for me, when important changes elsewhere in the
library forced me to maintain this code just to keep its tests
passing).

I'm going to deprecate it for GCC 16 and will remove it for GCC 17.