This is the mail archive of the 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: Find more ObjC methods

On Oct 7, 2003, at 10:27 AM, Alexander Malmberg wrote:

in situations where, it can
determine that foo responds to bar. So now GCC does not
issue warnings in such cases. And we are discussing in this
thread whether we should add new command line option to
enable 'wrong' compiler warnings.

The warning isn't wrong unless you don't want to follow this convention (methods declared only in an @implementation are private to that @implementation).

As David Ayers and I have explained, we find this convention, and the
support from the compiler in adhering to it, useful. If you don't,
you're free to not enable/disable the warning (note "optional").

I do not approve such patch.

Why? The warning would be optional, so doing this gains you nothing, it
merely prevents those who do want the warning from getting it. It seems
that you want to remove a feature that others use just because you don't
use it, which is not a particularly nice attitude.

The reason why I'm opposing such warning is that in the long run it is confusing to end user. How will developer distinguish "foo may not respond to bar" warning is real or not? This leads to, "Do I trust what compiler is saying?"

But if you want this badly and Objective-C maintainers approve
it then go ahead! Its better if wording is different for the
cases where compiler can actually determine that foo responds
to bar, but forced to emit warning because user wants it.


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