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.
