> On Apr 30, 2017, at 2:05 PM, Quincey Morris > <[email protected]> wrote: > > On Apr 30, 2017, at 09:46 , Jonathan Schleifer <[email protected] > <mailto:[email protected]>> wrote: >> >> the others do not list nonatomic - making them atomic, which is the default > > You and Charles are both right, in a way. > > 1. What you describe is the original semantics of property atomicity. For > some reason, the decision was taken to make properties default to “atomic”, > but no attempt was made to convert any pre-existing getter/setter > implementations, and no attempt was made to verify that any new custom > accessors provided atomicity. The whole thing was broken right from the start. > > 2. Although nothing syntactic has ever changed, common usage has changed over > the years, to (informally) regard the default (omission of attribute) and > explicit “atomic” as different things, in terms of API contract. The usage > has come to be that only properties explicitly marked “atomic” can be > reasonably assumed to be making an API contract, and that properties without > the attribute make no API contract (even if they happen to be atomic as an > implementation detail).
Yes, this is well-put. Programming languages are interpreted by machines, but APIs are designed by humans, and human standards should be applied when understanding them. A human understanding of a contract would always tell us that incidental things that aren't explicitly spelled out as promises are not promises at all. That's just as true in language and library design as it is in law. "atomic" was added for two reasons: because it makes sense for properties that actually guarantee atomicity to be explicit about it, and because it enables a warning (much requested) about synthesizing an implicitly atomic property. > Note that atomic/nonatomic, like strong/weak/etc, have an ambiguous role in > property declarations. Their actual effect is to guide the code that’s > generated for a *synthesized* property, and nothing else — they affect > nothing the compiler does at a call site. At the same time, they’re > (informally and unreliably) taken as an API contract for users of the > property. > > What ought to have happened, once Apple realized that this ambiguity existed, > was to move synthesis-related attributes to the @synthesize statement, and to > leave attributes on @property statements as “advice” to callers. Instead, > Apple (inadvisedly, IMO) went in the opposite direction, making @synthesize > statements optional, and locking the @synthesize-related attributes to the > @property statement. Hilarity ensued, of which this thread is the most recent > manifestation. I agree that, in the abstract, it would be better language design to allow these things to be controlled by explicit synthesis. On the other hand, that would introduce even more complexity and ambiguity to an already over-complex language design; and weakness of reference, for a settable property, is actually an extremely important part of the contract. John.
_______________________________________________ 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]
