------- Comment #25 from mark at codesourcery dot com 2008-01-16 22:27 ------- Subject: Re: [4.3 Regression] Revision 129442 breaks libstc++ API
bkoz at gcc dot gnu dot org wrote: > I believe there is a bit of a bias here, in that it's OK to make FE changes, > but even well-documented and warned lib changes are not ok? What's up with > that? I assert the right to make API changes, including removal of deprecated > items. No, as I've said before, I think the C++ maintainers -- mostly me! -- were just plain wrong about some of the changes made. I think that some of the changes that were made were necessary because they were the only way to increase our ability to accept correct, conformance code. In other words, sometimes we had to choose between backwards-compatibility and correctness. In those cases, I think we were right to choose correctness. In other cases, we could have kept compatibility, but didn't. In some of those cases, I think we -- and again, mostly, be "we" I mean "I"! -- didn't try hard enough to keep backwards compatibility. We've being punished for that. (Note that there's a recent discussion about making things that are errors by default into warnings by default -- thereby making the compiler more lenient.) My -- possibly incorrect -- understanding is that in this case the problem with the old headers is not that it prevents implementation of an ISO-conformant C++ library, but just that they're a pain to keep around. My feeling is that we should be very reluctant to break backwards compatibility "for maintenance reasons". Fedora (or any other GNU/Linux distribution) packages are not a good measure of the problem. They're good sample of free and/or open-source codebases compiled with G++, but they're a poor sample of all code compiled with G++. We see a lot of dusty-deck C++ code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33831
