This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFC: Proposed patch for PR c++/7874


Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Ian Lance Taylor <ian@airs.com> writes:
> 
> | Here is a proposed patch to stop injecting friend functions.  For
> | backward compatibility support, this patch includes a new option,
> | -finject-friend-functions, which supports the old behaviour.  My
> | expectation is that this option--which is implemented in six lines of
> | code, counting the lines in c.opt--would be removed in a future
> | release. 
> 
> I think a new option is not needed, especially for this sort of
> constructs that are already scheduled to be dropped.

I certainly think the C++ maintainers should make the decision on
this.

However, my general feeling is that we currently have code which works
and which the compiler accepts with no warning.  Yes, we marked it as
deprecated in the release notes, but we didn't give people any help in
fixing their code.  I think it is bad release engineering to make a
new release in which the compiler rejects this same code as an error
with no fallback.  Certainly there are regular user complaints about
this.

I think it would be completely reasonable to issue a deprecated
warning on any use of -finject-friend-functions, along the lines of
"this option will be removed in a later release".  Or we could use
-fpermissive--Richard Guenther suggested that on IRC.

But I think it's a mistake to break working code with no warning from
the compiler.

As I said, I do think the C++ maintainers should make the final
decision.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]