RFC: Deprecate libstdc++ Policy-Based Data Structures

[Jonathan Wakely]

On Wed, 15 May 2019, 01:43 NightStrike wrote:
>
> On Mon, May 13, 2019 at 12:29 PM Jonathan Wakely <jwakely@redhat.com> wrote:
> >
> > I'm including gcc@gcc.gnu.org here for visibility, but the discussion
> > really belongs on the libstdc++ list so please limit replies to there.
> >
> > I'd like to discuss deprecating (and eventually removing) the
> > libstdc++-v3/include/ext/pb_ds extensions. For information on them see
> > https://gcc.gnu.org/onlinedocs/libstdc++/manual/policy_data_structures.html
> >
> > There has been exactly one (1) bug report for them in the past seven
> > years since the code stabilized (i.e. when Benjamin stopped working on
> > them). The bug reporter and the author of the fix have both confirmed
> > they don't use them for anything "serious" that requires them to be
> > shipped as part of GCC (see PR 62045).
> >
> > I can find no uses of them in https://codesearch.debian.net or
> > https://codesearch.isocpp.org/
> >
> > They require occasional tweaking but many of the changes are just
> > touching comments. However, running the tests is very slow, see
> > https://gcc.gnu.org/ml/libstdc++/2019-03/msg00012.html
> >
> > I'd like to consider deprecating them, and then removing them from the
> > libstdc++ tree. There's no reason the code can't be moved to a
> > separate project on sourceware.org (and/or gitlab, github etc.) but I
> > don't think it needs to be maintained as part of libstdc++.
>
> I don't think a lengthy testsuite run of several minutes is a good
> reason to remove an existing feature.


Complete lack of maintainers or users is though. Making the testsuite
faster would be a nice side effect.


> I also don't think that
> searching open code is indicative enough of the widespread use of GCC
> features.


I disagree. It's not comprehensive, but it's certainly indicative. And
I also have access to Red Hat's bug database, with reports from
customers seeking support with their proprietary software, as well as
Fedora bugs. The only report that even mentions these extensions is a
filesystem bug where one of the pb_ds header files on disk got
corrupted by a codegen bug affecting the kernel. It doesn't look like
the user was actually including the header though.

If there are loads of users in private code bases why has nobody
reported bugs like the pathological heap performance, until somebody
happened to play with it in a toy program?

Why has nobody requested that the code be updated to support rvalue
references, or 'emplace' members, or transparent comparison functions,
or C++11 allocators?


> I personally was unaware of this feature.  Now that I am, I
> can see it being used in a number of closed projects that I work on.

The code has been there for years. If deprecating it makes people try
it and start using it, then it can be undeprecated. That would be
better than doing nothing and nobody using it for another decade.


> For these projects, it is immensely easier to get approval for using
> library features included with the compiler compared to any external
> library.


I know how such things work, but frankly "It's already installed" is a
lazy and lame reason to rely on code that hasn't been maintained or
even used for the best part of a decade.

Libstdc++ is an implementation of the C++ Standard Library. We have
too much work to do just keeping up with the standard (e.g. C++17 is
still not complete in 2019). Supporting a huge body of code (more than
20kloc) that nobody uses has a cost. "This looks useful to me ...
maybe" is not a good enough reason for us to continue supporting it on
your behalf. Lots of things might be useful to somebody, but that
doesn't mean they belong in libstdc++. If somebody was maintaining
this code it would be a different story. If customers with support
contracts made a case for their vendors to support it that would also
be a different story (I'm sending this from my personal account to be
clear that my desire to deprecate this is based on a personal view,
for the benefit of the upstream GCC project, not my employer's
position).

Your objection is noted, but I'm still inclined to deprecate them.
Deprecation can always be reversed if users and/or maintainers
actually appear. Thanks for replying though, that was the point of the
RFC mail.