[Bug libstdc++/114498] New: Consider deprecating then removing TR1 headers

[Bug libstdc++/114498] New: Consider deprecating then removing TR1 headers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498

            Bug ID: 114498
           Summary: Consider deprecating then removing TR1 headers
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

We should decide whether we want to keep std::tr1::shared_ptr etc. forever.

Those headers are virtually unmaintained, and just increase testing burden.

They do provide functionality that isn't otherwise available from libstdc++ in
C++98/C++03 mode. But does anybody care? Is anybody stuck in C++98/C++03 mode,
but also upgrading to modern GCC versions, and also relying on non-standard TR1
components that aren't actually in the C++03 standard? Can they just use Boost
instead?

At some point we might want to have the same discussion for
<experimental/optional> and LFTSv1 components, and <experimental/filesystem
too. But that seems further off.

[Bug libstdc++/114498] Consider deprecating then removing TR1 headers

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'd say deprecating them for a release aka hiding behind a
-D_YES_I_WANT_TR1_HEADERS and otherwise issueing #error and then axing them
should be OK.

Preferably tell people about a suitable replacement (or point to an URL)
within that #error.

If you are quick you can do the deprecation for GCC 14 ...

Are the headers usable with -std=c++11 or later?  Only allowing them with
-std=c++98/c++03 might be another option, so at least conflicts with new
features shouldn't be an issue then.

[Bug libstdc++/114498] Consider deprecating then removing TR1 headers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I'd say deprecating them for a release aka hiding behind a
> -D_YES_I_WANT_TR1_HEADERS and otherwise issueing #error and then axing them
> should be OK.
> 
> Preferably tell people about a suitable replacement (or point to an URL)
> within that #error.

Yeah, we can use a deprecated attribute with a suggestion. We already have
_GLIBCXX_DEPRECATED_SUGGEST for that. And if we remove them completely, we can
keep the headers and use #error to give suggestions.

> If you are quick you can do the deprecation for GCC 14 ...

I'm not going to try, there are higher priority things I can do for 14 :-)

> Are the headers usable with -std=c++11 or later?

Yes, but mostly not useful, because most of the features were added to C++11
anyway, e.g. std::tr1::shared_ptr is superseded by std::shared_ptr,
std::tr1::function is superseded by std::function, etc.

> Only allowing them with
> -std=c++98/c++03 might be another option, so at least conflicts with new
> features shouldn't be an issue then.

Conflicts aren't an issue. The only real reason to remove them is just to have
less code to maintain + test. But the maintenance burden is very low, so it's
just the time spent testing them in a testsuite that's already large and slow.