4

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?

Chris Devereux
  • 5,453
  • 1
  • 26
  • 32

2 Answers2

9

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.)

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • Would you mind redacting the stuff about how to override the naming conventions? ;) – Chris Devereux Feb 12 '12 at 16:34
  • Just as soon as its removed from http://clang.llvm.org/docs/AutomaticReferenceCounting.html. :D But Chris is correct that this is not generally a good solution. It is a better solution than leaking and crashing under ARC. But the correct solution is to fix your names to conform to ObjC naming conventions. – Rob Napier Feb 12 '12 at 19:15
1

It's an ounce of prevention, I'd assume. Incidentally, it's not foolproof in larger systems because selectors do not need to match and matching is all based on the translation, so it could still blow up on you if you are not writing your program such that it introduces type safety. Something is better than nothing, though!

The compiler wants to know about parameters and return types, potentially annotations and out parameters. ObjC has defaults to fall back on, but it's a good source of multiple types of bugs as the compiler does more for you.

There are a number of reasons you should introduce type safety and turn up the warning levels. With ARC, there are even more. Regardless of whether it is truly necessary, it's a good direction for an objc compiler to move towards (IMHO). You might consider C99 safer than ObjC 2.0 in this regard ;)

If there really is a restriction for codegen, I'd like to hear it.

Community
  • 1
  • 1
justin
  • 104,054
  • 14
  • 179
  • 226
  • Sure. But what's special about ARC in this case? If the intention was to ramp up the type safety in general, why only make this an error under ARC, and why add the 'ARC' prefix to the error message? – Chris Devereux Feb 12 '12 at 01:04
  • @Chris ah, but `performSelector:` *could* have been implemented using the assistance of the runtime -- it did not *need* to be an error. same thing here. the rules for parameter types of undeclared selectors are defined. – justin Feb 12 '12 at 01:19