> On Apr 30, 2017, at 11:46 AM, Jonathan Schleifer <[email protected]> > wrote: > > Am 30.04.2017 um 17:32 schrieb Charles Srstka <[email protected] > <mailto:[email protected]>>: > >> I’m sure there’s probably a property somewhere in Foundation that’s marked >> atomic, but so far I haven’t been able to find one. Properties that are >> marked atomic look like this: > > There's only 5 that are declared nonatomic, the others do not list nonatomic > - making them atomic, which is the default. But they are not actually atomic, > as they are implemented using return [[foo retain] autorelease].
As you say, they are *not* actually atomic. >> @property (atomic, strong) Foo *foo; >> >> Properties that are marked “I don’t know whether this is atomic or not, >> check the documentation to find out” are marked like this: >> >> @property (strong) Foo *foo; > > No, this is not true. The atomic keyword is quite new and didn't even exist > initially. atomic is just the default. See also > https://lists.apple.com/archives/objc-language/2012/Mar/msg00022.html > <https://lists.apple.com/archives/objc-language/2012/Mar/msg00022.html> on > the introduction of the atomic keyword. Five years is not exactly new—even ARC itself is barely older. The ‘atomic’ keyword was added precisely to solve the problem I described; the absence of ‘nonatomic’ is an extremely poor way to specify atomicity, because many—even most—properties so declared are not even atomic. Today, the keyword exists, and it is the only way (other than documentation) to actually guarantee that your property is atomic. Otherwise, there is no way for the user of the API to know whether the property is atomic or not, so it is not safe to use in a manner that assumes atomicity, and calling code must assume that it is nonatomic. It’s worth pointing out that the Foundation properties in question were all added after the atomic keyword was introduced, as you can see for yourself by downloading old Xcode versions and inspecting them. >> Foundation almost entirely uses the latter. The reason is because the >> properties themselves often predate the @property syntax, being originally >> presented as manually-written getters and setters. At some point, they were >> converted to @properties, probably in preparation for the introduction of >> Swift, since it actually imposes different syntax requirements on properties >> and ordinary methods, unlike Objective-C. Since vetting the entire >> Foundation framework is a long and arduous task, I assume that the >> developers probably reasoned that the documentation had been serving as an >> adequate reference for the atomicity of the properties up until that point, >> and would continue to do so. > > Again, this is not really true. When properties were introduced, there wasn't > even an atomic attribute. When properties were introduced, there wasn’t even a @property keyword at all. The concept of properties goes back far further than Objective-C 2.0. >> As for why a property that’s not marked is made atomic if it’s automatically >> synthesized? I think that was a poor decision. You certainly can’t rely on >> the atomicity of a property so marked; it will only be atomic if the >> developer hasn’t provided their own implementation, and even if they *have*, >> if their intention wasn’t deliberately to make it atomic, there’s no way to >> tell whether they might provide their own accessor in the future and break >> it. > > Yep, that is indeed the problem I am pointing out here. They claim to be > atomic - while they're not. It's better to declare them nonatomic and still > retain + release (worst case then is that you retain more than necessary). > That at least doesn't claim something they are not. Declaring them atomic > declares them to be something they're not. They don’t make any claim at all. Marking them ‘atomic’ would be making a claim. The fact that there once wasn’t a way to make the claim is neither here nor there; this is 2017, not 2011. Charles
_______________________________________________ Do not post admin requests to the list. They will be ignored. Objc-language mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com This email sent to [email protected]
