> On Apr 30, 2017, at 8:15 AM, Jonathan Schleifer <[email protected]> > wrote: > >> >> If the property has ever autoreleased its result, it can be difficult for >> binary compatibility reasons to make it no longer autorelease. > > What was the rationale then to make atomic the default? And why is everything > in Foundation marked atomic, when a quick look in a disassembler reveals it's > not? Shouldn't it be marked nonatomic and the fact that it still retains and > autoreleases for historic reasons becomes an implementation detail then? > Seems closer to what it actually does.
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: @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; 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. 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. Given that, thanks to Foundation, it’s probably safe to say that the vast majority of unmarked properties are not actually atomic, any property that presents itself this way must be treated as if it were nonatomic. And given *that*, the atomic default behavior does not actually gain us anything to compensate for the performance drawbacks it brings. 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]
