Does `nonatomic` makes sense in a `readonly` declared property (including class property)?

Question

EDIT: This question applies to normal declared properties as well (not only to class properties)!

Original Post:

Lets say I have the public class method sharedInstance which is currently implemented as a getter method:

@interface MyClass

+ (instancetype)sharedInstance;

- (void)doSomething;

@end

@implementation MyClass

+ (instancetype)sharedInstance {
    static MyClass *shared = nil;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        shared = [[MyClass alloc] init];
    });
    return shared;
}

@end

Accessing this method in Swift 3.0 would look like this: MyClass.shared().doSomething()

So to make it more swifty we should change the class method to a class property (new in Xcode 8. but actually I can't find it in the Apple Docu, only in WWDC 2016 video)

@interface MyClass

@property (class, nonatomic, readonly) MyClass *sharedInstance;

- (void)doSomething;

@end

// implementation stays the same

Now in Swift code: MyClass.shared.doSomething()

So does nonatomic/atomic property modifier (don't know the exact term) even makes sense for a getter method which I implement myself in objc?

Answer 1

The atomic/nonatomic modifiers have no effect in your case, for multiple reasons.

The main reason is that atomicity keywords affect only generated code (i.e. synthesized accessor methods). When you declare a @property in your interface and then implement it with a method (or method pair) in your implementation, the compiler isn't generating code, so your atomicity keyword is ignored.

There are a few ways to get to this situation, and you're triggering a couple of them:

• First, you have a class property. The compiler can't synthesize accessors or storage for class properties — which means no code generation, so atomicity doesn't apply.

• Second, in most common uses of readonly properties, the @property declaration is backed by a manually implemented getter method — which means there's no code generation and thus atomicity doesn't apply.

  _{(Note you can also have instance properties declared as readonly in a public interface and synthesized due to a private readwrite redeclaration in your implementation. In that case, not only does atomicity apply, you have to make the atomicity keywords match between your public and private declarations. You can also synthesize just a getter and work directly with the backing ivar in your implementation.)}

Because specifying either atomic or nonatomic for this property does nothing either way, you're free to just leave atomicity keywords out of your declaration entirely. (The compiler will assume atomic, but as noted that assumption has no effect.)

Answer 2

It makes perfect sense. The declaration of a property gives the user of the class information. An user of the class is allowed to expect from the – synthesized or manual – implementation, what you tell in the declaration. The user cannot even know, whether it is synthesized or not.

If you implement the getter (or whatever accessor) yourself, you should reflect the atomicity of your implementation in the declaration of the property. If you have a non-atomic implementation, you should add that to the declared property.