Question

Maybe it’s useful if calling a method that MyClass doesn’t understand on a something typed MyClass is an error rather than a warning since it’s probably either a mistake or going to cause mistakes in the future…

However, why is this error specific to ARC? ARC decides what it needs to retain/release/autorelease based on the cocoa memory management conventions, which would suggest that knowing the selector’s name is enough. So it makes sense that there are problems with passing a SEL variable to performSelector:, as it’s not known at compile-time whether the selector is an init/copy/new method or not. But why does seeing this in a class interface or not make any difference?

Am I missing something about how ARC works, or are the clang warnings just being a bit inconsistent?

Answer 1

ARC decides what it needs to retain/release/autorelease based on the cocoa memory management conventions, which would suggest that knowing the selector’s name is enough.

This is just one way that ARC determines memory management. ARC can also determine memory management via attributes. For example, you can declare any typedef retainable using __attribute__((NSObject)) (never, ever do this, but it’s legal). You can also use other attributes like __attribute((ns_returns_retained)) and several others to override naming conventions (these are things you might reasonably do if you couldn’t fix the naming; but it’s much better to fix the naming).

Now, imagine a case where you failed to include the header file that declares these attributes in some files but not others. Now, some compile units (.m files) memory manage it one way and some memory manage it another. Hijinks ensure. This is much, much worse than the situation without ARC, and the resulting bugs would be mindbending because some ARC code would do one thing and other ARC code would do something different.

So, yeah, don’t do that. (Of course you should never ignore warnings in Objective-C anyway, but this is a particularly nasty situation.)