Why does a declared property use both retain and readonly?

Why does a declared property use both retain and readonly?

up vote 23 down vote favorite 12

I've noticed that some of Apple's examples include both a retain and readonly modifier on properties. What's the point of including retain if no setter gets generated when we're using the readonly modifier? Example: @property (retain, readonly) NSString *title; from the AnimatedTableView sample. up vote 23 down vote favorite 12 I've noticed that some of Apple's examples include both a retain and readonly modifier on properties. What's the point of including retain if no setter gets generated when we're using the readonly modifier? Example: @property (retain, readonly) NSString *title; from the AnimatedTableView sample. objective-c  memory-management  declared-property share improve this question edited May 9 '14 at 8:27 Josh Caswell 44.1k 8 76 119 asked  Dec 19 '09 at 17:05 Matt 405 1 5 13   add a comment 2 Answers active oldest votes up vote 17 down vote accepted You can include a second, private readwrite declaration in a class extension. The memory management scheme for all references needs to match IIRC, so you get silliness like "readonly, retain". share improve this answer answered  Dec 19 '09 at 17:10 Chuck 150k 15 199 305   3   It isn't entirely silly; the matrix of modifiers vs. @synthesize is such that the getter's code can change. Trying to suss out exactly which modifiers should be able to be added vs. which should #warn would rife with minutia and hard to ultimately understand. Better to simply go with "must be same except readonly->readwrite". –   bbum  Dec 19 '09 at 19:28 Figured i should expand on my comment.... –   bbum  Feb 23 '10 at 22:20 add a comment up vote 36 down vote Or, more specifically, (readonly, retain) enables a pattern like this: Foo.h: @interface StuffHolder:NSObject @property(readonly, retain) MyStuff *stuff; @end Foo.m: @interface StuffHolder() @property(readwrite, retain) MyStuff *stuff; @end @implementation StuffHolder @synthesize stuff; @end The end result is a property that is publicly readonly while being readwrite within the implementation and for whom both setter and getter are synthesized automatically by the compiler. A warning could be generated in the case of no (readwrite, retain) override in the class extension -- something akin to statement without an effect -- but it would be more confusing than beneficial. There are also a whole slew of different edge cases across the combinations that would equally warrant a warning, but don't really indicate an actual problem. The decision was made to largely accept the various patterns without complaint for simplicity's sake (since they aren't correctness issues).