if ([self respondsToSelector: @selector(foo)])
[self foo];
That expression is only "perfectly safe" if there are no arguments and no return value. If any type information is required, @selector(foo)
is insufficient.
Even then, I suspect that there are architectures whose ABI are such that the no-arg-no-return case would actually require that type knowledge be available to the compiler to be able to generate code that is absolutely guaranteed correct.
That is to say, your example of fooWithInteger:
and/or fooWithX:y:z:
could not possibly be compiled correctly without the full type information available due to the vagaries of the C language and the architecture specific ABI.
As well, to allow the compiler to compile that without warning would require the compiler to collude a runtime expression -- respondsToSelector:
must be dynamically dispatched -- with a compile time expression. Compilers hate that.