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.

Reply via email to