Why does using "selector" cause a compiler warning, but @selector(selector) doesn't?

Question

I was messing around and just tried implementing a simple non-block / delegate callback function.

Class A.m
@implementation noblocks
-(void)logSomethingAndNotify:(id)object andCallSelector:(SEL)selector {

    //some task
    NSLog(@"TRYING THIS OUT");

    //implement callback functionality
    if ([object respondsToSelector:@selector(selector)]) {
        [object performSelector:@selector(selector) withObject:object];
    }

}

@end

Class B.m
- (void)viewDidLoad {
    [super viewDidLoad];
    ClassA *noblock = [noblocks new];
    [ClassA logSomethingAndNotify:self andCallSelector:@selector(addSubviewAfterDelay)];
}

-(void)addSubviewAfterDelay {
    double delayInSeconds = 2.0;
    dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, delayInSeconds * NSEC_PER_SEC);
    dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
        UIView *view = [[UIView alloc]initWithFrame:CGRectMake(50, 50, 100, 100)];
        view.backgroundColor = [UIColor blueColor];
        [self.view addSubview:view];
    });
}

In the implementation file of Class A, if I change this statement:

if ([object respondsToSelector:@selector(selector)]) {            
[object performSelector:@selector(selector) withObject:object];
   }

to the selector the way it is represented as a method parameter

if ([object respondsToSelector:selector]) {
[object performSelector:selector withObject:object];
}

then I get a memory leak warning from the compiler.

I understand that given the dynamic runtime of Objective-C, sending a selectorless message to an unknown object can potentially be problematic - we don't know the return type of the method and can't be sure that we should retain the object returned (if there is one). What I don't understand is why using performSelector:@selector(selector) vs just using performSelector:selector DOESN'T cause any ARC warning.

This question is NOT a duplicate of others addressing the compiler warning - my question is not about WHY the error is shown so much as why ONE way shows a warning while the OTHER does not.

Using @selector(SEL) isn't valid as the whole point of the @selector keyword is to generate/retrieve the SEL for the specified selector. Therefore the first case is invalid. The reason for the warning is well documented here and elsewhere. — trojanfoe
Invalid how? Both compile and run just fine, it's just that one throws a compiler error and I don't understand why the other one doesn't. It's also not well documented when comparing both cases; I've looked all over. The error message is addressed, not the comparison of cases. — karan satia
also, nowhere in my posted code have I written @selector(SEL). — karan satia
It's invalid as the argument to @selector() should be a method name. I used the notation @selector(SEL) to illustrate the fact that you are calling @selector() on a variable of type SEL. — trojanfoe
I see. Could you then explain why using @selector(SEL) throws no error while using performSelector:SEL does throw an ARC error? I understand why the entire thing shouldn't be used, it was just a little test. — karan satia

bbum bbum · Accepted Answer · 2016-03-02T21:09:33

@selector(selector) isn't doing what you think it is. :)

Consider:

    SEL selector = @selector(hash);
    NSLog(@"%s %s", selector, @selector(selector));

This outputs (relying on the fact that an SEL is really a char* as an implementation detail that you should never rely on outside of experiments like this):

   asdfasdfa[71281:7385265] hash selector

@selector(selector) produces a constant value that doesn't trigger the ARC memory warning because the compiler can reason about the code path appropriately.

I.e. consider:

    SEL bob = @selector(dobbs);
    NSLog(@"%s %s", bob, @selector(bob));

Produces:

    asdfasdfa[71313:7394673] hobbs bob

The variable bob refers to the SEL dobbs whereas @selector(bob) produces the SEL bob.

Why does using "selector" cause a compiler warning, but @selector(selector) doesn't?

2 Answers