Objective C Automatic Reference Counting (ARC)
Uploaded by
Raj Bahadur MauryaObjective C Automatic Reference Counting (ARC)
Uploaded by
Raj Bahadur Maurya06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
ObjectiveC Automatic Reference Counting (ARC)
1 About this document
1.1 Purpose
1.2 Background
1.3 Evolution
2 General
3 Retainable object pointers
3.1 Retain count semantics
3.2 Retainable object pointers as operands and arguments
3.2.1 Consumed parameters
3.2.2 Retained return values
3.2.3 Unretained return values
3.2.4 Bridged casts
3.3 Restrictions
3.3.1 Conversion of retainable object pointers
3.3.2 Conversion to retainable object pointer type of expressions with known semantics
3.3.3 Conversion from retainable object pointer type in certain contexts
4 Ownership qualification
4.1 Spelling
4.1.1 Property declarations
4.2 Semantics
4.3 Restrictions
4.3.1 Weakunavailable types
4.3.2 Storage duration of __autoreleasing objects
4.3.3 Conversion of pointers to ownershipqualified types
4.3.4 Passing to an out parameter by writeback
4.3.5 Ownershipqualified fields of structs and unions
4.4 Ownership inference
4.4.1 Objects
4.4.2 Indirect parameters
4.4.3 Template arguments
5 Method families
5.1 Explicit method family control
5.2 Semantics of method families
5.2.1 Semantics of init
5.2.2 Related result types
6 Optimization
6.1 Object liveness
6.2 No object lifetime extension
6.3 Precise lifetime semantics
7 Miscellaneous
7.1 Special methods
7.1.1 Memory management methods
7.1.2 dealloc
7.2 @autoreleasepool
7.3 ExternallyRetained Variables
7.4 self
7.5 Fast enumeration iteration variables
7.6 Blocks
7.7 Exceptions
7.8 Interior pointers
7.9 C retainable pointer types
7.9.1 Auditing of C retainable pointer interfaces
8 Runtime support
8.1 id objc_autorelease(id value);
8.2 void objc_autoreleasePoolPop(void *pool);
8.3 void *objc_autoreleasePoolPush(void);
8.4 id objc_autoreleaseReturnValue(id value);
8.5 void objc_copyWeak(id *dest, id *src);
8.6 void objc_destroyWeak(id *object);
8.7 id objc_initWeak(id *object, id value);
8.8 id objc_loadWeak(id *object);
clang.llvm.org/docs/AutomaticReferenceCounting.html 1/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
8.9 id objc_loadWeakRetained(id *object);
8.10 void objc_moveWeak(id *dest, id *src);
8.11 void objc_release(id value);
8.12 id objc_retain(id value);
8.13 id objc_retainAutorelease(id value);
8.14 id objc_retainAutoreleaseReturnValue(id value);
8.15 id objc_retainAutoreleasedReturnValue(id value);
8.16 id objc_retainBlock(id value);
8.17 void objc_storeStrong(id *object, id value);
8.18 id objc_storeWeak(id *object, id value);
1 About this document
1.1 Purpose
The first and primary purpose of this document is to serve as a complete technical specification of Automatic Reference Counting. Given a core
ObjectiveC compiler and runtime, it should be possible to write a compiler and runtime which implements these new semantics.
The secondary purpose is to act as a rationale for why ARC was designed in this way. This should remain tightly focused on the technical design
and should not stray into marketing speculation.
1.2 Background
This document assumes a basic familiarity with C.
Blocks are a C language extension for creating anonymous functions. Users interact with and transfer block objects using block pointers, which
are represented like a normal pointer. A block may capture values from local variables; when this occurs, memory must be dynamically allocated.
The initial allocation is done on the stack, but the runtime provides a Block_copy function which, given a block pointer, either copies the underlying
block object to the heap, setting its reference count to 1 and returning the new block pointer, or (if the block object is already on the heap) increases
its reference count by 1. The paired function is Block_release, which decreases the reference count by 1 and destroys the object if the count
reaches zero and is on the heap.
ObjectiveC is a set of language extensions, significant enough to be considered a different language. It is a strict superset of C. The extensions can
also be imposed on C++, producing a language called ObjectiveC++. The primary feature is a singleinheritance object system; we briefly describe
the modern dialect.
ObjectiveC defines a new type kind, collectively called the object pointer types. This kind has two notable builtin members, id and Class; id is the
final supertype of all object pointers. The validity of conversions between object pointer types is not checked at runtime. Users may define classes;
each class is a type, and the pointer to that type is an object pointer type. A class may have a superclass; its pointer type is a subtype of its
superclass’s pointer type. A class has a set of ivars, fields which appear on all instances of that class. For every class T there’s an associated
metaclass; it has no fields, its superclass is the metaclass of T’s superclass, and its metaclass is a global class. Every class has a global object
whose class is the class’s metaclass; metaclasses have no associated type, so pointers to this object have type Class.
A class declaration (@interface) declares a set of methods. A method has a return type, a list of argument types, and a selector: a name like
foo:bar:baz:, where the number of colons corresponds to the number of formal arguments. A method may be an instance method, in which case it
can be invoked on objects of the class, or a class method, in which case it can be invoked on objects of the metaclass. A method may be invoked by
providing an object (called the receiver) and a list of formal arguments interspersed with the selector, like so:
[receiver foo: fooArg bar: barArg baz: bazArg]
This looks in the dynamic class of the receiver for a method with this name, then in that class’s superclass, etc., until it finds something it can
execute. The receiver “expression” may also be the name of a class, in which case the actual receiver is the class object for that class, or (within
method definitions) it may be super, in which case the lookup algorithm starts with the static superclass instead of the dynamic class. The actual
methods dynamically found in a class are not those declared in the @interface, but those defined in a separate @implementation declaration;
however, when compiling a call, typechecking is done based on the methods declared in the @interface.
Method declarations may also be grouped into protocols, which are not inherently associated with any class, but which classes may claim to follow.
Object pointer types may be qualified with additional protocols that the object is known to support.
Class extensions are collections of ivars and methods, designed to allow a class’s @interface to be split across multiple files; however, there is still
a primary implementation file which must see the @interfaces of all class extensions. Categories allow methods (but not ivars) to be declared post
hoc on an arbitrary class; the methods in the category’s @implementation will be dynamically added to that class’s method tables which the category
is loaded at runtime, replacing those methods in case of a collision.
clang.llvm.org/docs/AutomaticReferenceCounting.html 2/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
In the standard environment, objects are allocated on the heap, and their lifetime is manually managed using a reference count. This is done using
two instance methods which all classes are expected to implement: retain increases the object’s reference count by 1, whereas release decreases
it by 1 and calls the instance method dealloc if the count reaches 0. To simplify certain operations, there is also an autorelease pool, a threadlocal
list of objects to call release on later; an object can be added to this pool by calling autorelease on it.
Block pointers may be converted to type id; block objects are laid out in a way that makes them compatible with ObjectiveC objects. There is a
builtin class that all block objects are considered to be objects of; this class implements retain by adjusting the reference count, not by calling
Block_copy.
1.3 Evolution
ARC is under continual evolution, and this document must be updated as the language progresses.
If a change increases the expressiveness of the language, for example by lifting a restriction or by adding new syntax, the change will be annotated
with a revision marker, like so:
ARC applies to ObjectiveC pointer types, block pointer types, and [beginning Apple 8.0, LLVM 3.8] BPTRs declared within extern
"BCPL" blocks.
For now, it is sensible to version this document by the releases of its sole implementation (and its host project), clang. “LLVM X.Y” refers to an open
source release of clang from the LLVM project. “Apple X.Y” refers to an Appleprovided release of the Apple LLVM Compiler. Other organizations
that prepare their own, separatelyversioned clang releases and wish to maintain similar information in this document should send requests to cfe
dev.
If a change decreases the expressiveness of the language, for example by imposing a new restriction, this should be taken as an oversight in the
original specification and something to be avoided in all versions. Such changes are generally to be avoided.
2 General
Automatic Reference Counting implements automatic memory management for ObjectiveC objects and blocks, freeing the programmer from the
need to explicitly insert retains and releases. It does not provide a cycle collector; users must explicitly manage the lifetime of their objects, breaking
cycles manually or with weak or unsafe references.
ARC may be explicitly enabled with the compiler flag -fobjc-arc. It may also be explicitly disabled with the compiler flag -fno-objc-arc. The last of
these two flags appearing on the compile line “wins”.
If ARC is enabled, __has_feature(objc_arc) will expand to 1 in the preprocessor. For more information about __has_feature, see the language
extensions document.
3 Retainable object pointers
This section describes retainable object pointers, their basic operations, and the restrictions imposed on their use under ARC. Note in particular that
it covers the rules for pointer values (patterns of bits indicating the location of a pointedto object), not pointer objects (locations in memory which
store pointer values). The rules for objects are covered in the next section.
A retainable object pointer (or “retainable pointer”) is a value of a retainable object pointer type (“retainable type”). There are three kinds of
retainable object pointer types:
block pointers (formed by applying the caret (^) declarator sigil to a function type)
ObjectiveC object pointers (id, Class, NSFoo*, etc.)
typedefs marked with __attribute__((NSObject))
Other pointer types, such as int* and CFStringRef, are not subject to ARC’s semantics and restrictions.
Rationale
We are not at liberty to require all code to be recompiled with ARC; therefore, ARC must interoperate with ObjectiveC code which manages
retains and releases manually. In general, there are three requirements in order for a compilersupported referencecount system to provide
reliable interoperation:
The type system must reliably identify which objects are to be managed. An int* might be a pointer to a malloc’ed array, or it might be an
interior pointer to such an array, or it might point to some field or local variable. In contrast, values of the retainable object pointer types are
never interior.
The type system must reliably indicate how to manage objects of a type. This usually means that the type must imply a procedure for
incrementing and decrementing retain counts. Supporting singleownership objects requires a lot more explicit mediation in the language.
There must be reliable conventions for whether and when “ownership” is passed between caller and callee, for both arguments and return
values. ObjectiveC methods follow such a convention very reliably, at least for system libraries on Mac OS X, and functions always pass
objects at +0. The Cbased APIs for Core Foundation objects, on the other hand, have much more varied transfer semantics.
clang.llvm.org/docs/AutomaticReferenceCounting.html 3/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
The use of __attribute__((NSObject)) typedefs is not recommended. If it’s absolutely necessary to use this attribute, be very explicit about using
the typedef, and do not assume that it will be preserved by language features like __typeof and C++ template argument substitution.
Rationale
Any compiler operation which incidentally strips type “sugar” from a type will yield a type without the attribute, which may result in unexpected
behavior.
3.1 Retain count semantics
A retainable object pointer is either a null pointer or a pointer to a valid object. Furthermore, if it has block pointer type and is not null then it must
actually be a pointer to a block object, and if it has Class type (possibly protocolqualified) then it must actually be a pointer to a class object.
Otherwise ARC does not enforce the ObjectiveC type system as long as the implementing methods follow the signature of the static type. It is
undefined behavior if ARC is exposed to an invalid pointer.
For ARC’s purposes, a valid object is one with “wellbehaved” retaining operations. Specifically, the object must be laid out such that the ObjectiveC
message send machinery can successfully send it the following messages:
retain, taking no arguments and returning a pointer to the object.
release, taking no arguments and returning void.
autorelease, taking no arguments and returning a pointer to the object.
The behavior of these methods is constrained in the following ways. The term highlevel semantics is an intentionally vague term; the intent is that
programmers must implement these methods in a way such that the compiler, modifying code in ways it deems safe according to these constraints,
will not violate their requirements. For example, if the user puts logging statements in retain, they should not be surprised if those statements are
executed more or less often depending on optimization settings. These constraints are not exhaustive of the optimization opportunities: values held
in local variables are subject to additional restrictions, described later in this document.
It is undefined behavior if a computation history featuring a send of retain followed by a send of release to the same object, with no intervening
release on that object, is not equivalent under the highlevel semantics to a computation history in which these sends are removed. Note that this
implies that these methods may not raise exceptions.
It is undefined behavior if a computation history features any use whatsoever of an object following the completion of a send of release that is not
preceded by a send of retain to the same object.
The behavior of autorelease must be equivalent to sending release when one of the autorelease pools currently in scope is popped. It may not
throw an exception.
When the semantics call for performing one of these operations on a retainable object pointer, if that pointer is null then the effect is a noop.
All of the semantics described in this document are subject to additional optimization rules which permit the removal or optimization of operations
based on local knowledge of data flow. The semantics describe the highlevel behaviors that the compiler implements, not an exact sequence of
operations that a program will be compiled into.
3.2 Retainable object pointers as operands and arguments
In general, ARC does not perform retain or release operations when simply using a retainable object pointer as an operand within an expression.
This includes:
loading a retainable pointer from an object with nonweak ownership,
passing a retainable pointer as an argument to a function or method, and
receiving a retainable pointer as the result of a function or method call.
Rationale
While this might seem uncontroversial, it is actually unsafe when multiple expressions are evaluated in “parallel”, as with binary operators and
calls, because (for example) one expression might load from an object while another writes to it. However, C and C++ already call this
undefined behavior because the evaluations are unsequenced, and ARC simply exploits that here to avoid needing to retain arguments across
a large number of calls.
The remainder of this section describes exceptions to these rules, how those exceptions are detected, and what those exceptions imply
semantically.
3.2.1 Consumed parameters
clang.llvm.org/docs/AutomaticReferenceCounting.html 4/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
A function or method parameter of retainable object pointer type may be marked as consumed, signifying that the callee expects to take ownership
of a +1 retain count. This is done by adding the ns_consumed attribute to the parameter declaration, like so:
void foo(__attribute((ns_consumed)) id x);
- (void) foo: (id) __attribute((ns_consumed)) x;
This attribute is part of the type of the function or method, not the type of the parameter. It controls only how the argument is passed and received.
When passing such an argument, ARC retains the argument prior to making the call.
When receiving such an argument, ARC releases the argument at the end of the function, subject to the usual optimizations for local values.
Rationale
This formalizes direct transfers of ownership from a caller to a callee. The most common scenario here is passing the self parameter to init,
but it is useful to generalize. Typically, local optimization will remove any extra retains and releases: on the caller side the retain will be merged
with a +1 source, and on the callee side the release will be rolled into the initialization of the parameter.
The implicit self parameter of a method may be marked as consumed by adding __attribute__((ns_consumes_self)) to the method declaration.
Methods in the init family are treated as if they were implicitly marked with this attribute.
It is undefined behavior if an ObjectiveC message send to a method with ns_consumed parameters (other than self) is made with a null receiver. It is
undefined behavior if the method to which an ObjectiveC message send statically resolves to has a different set of ns_consumed parameters than
the method it dynamically resolves to. It is undefined behavior if a block or function call is made through a static type with a different set of
ns_consumed parameters than the implementation of the called block or function.
Rationale
Consumed parameters with null receiver are a guaranteed leak. Mismatches with consumed parameters will cause overretains or over
releases, depending on the direction. The rule about function calls is really just an application of the existing C/C++ rule about calling functions
through an incompatible function type, but it’s useful to state it explicitly.
3.2.2 Retained return values
A function or method which returns a retainable object pointer type may be marked as returning a retained value, signifying that the caller expects to
take ownership of a +1 retain count. This is done by adding the ns_returns_retained attribute to the function or method declaration, like so:
id foo(void) __attribute((ns_returns_retained));
- (id) foo __attribute((ns_returns_retained));
This attribute is part of the type of the function or method.
When returning from such a function or method, ARC retains the value at the point of evaluation of the return statement, before leaving all local
scopes.
When receiving a return result from such a function or method, ARC releases the value at the end of the fullexpression it is contained within,
subject to the usual optimizations for local values.
Rationale
This formalizes direct transfers of ownership from a callee to a caller. The most common scenario this models is the retained return from init,
alloc, new, and copy methods, but there are other cases in the frameworks. After optimization there are typically no extra retains and releases
required.
Methods in the alloc, copy, init, mutableCopy, and new families are implicitly marked __attribute__((ns_returns_retained)). This may be
suppressed by explicitly marking the method __attribute__((ns_returns_not_retained)).
It is undefined behavior if the method to which an ObjectiveC message send statically resolves has different retain semantics on its result from the
method it dynamically resolves to. It is undefined behavior if a block or function call is made through a static type with different retain semantics on
its result from the implementation of the called block or function.
Rationale
Mismatches with returned results will cause overretains or overreleases, depending on the direction. Again, the rule about function calls is
really just an application of the existing C/C++ rule about calling functions through an incompatible function type.
clang.llvm.org/docs/AutomaticReferenceCounting.html 5/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
3.2.3 Unretained return values
A method or function which returns a retainable object type but does not return a retained value must ensure that the object is still valid across the
return boundary.
When returning from such a function or method, ARC retains the value at the point of evaluation of the return statement, then leaves all local
scopes, and then balances out the retain while ensuring that the value lives across the call boundary. In the worst case, this may involve an
autorelease, but callers must not assume that the value is actually in the autorelease pool.
ARC performs no extra mandatory work on the caller side, although it may elect to do something to shorten the lifetime of the returned value.
Rationale
It is common in nonARC code to not return an autoreleased value; therefore the convention does not force either path. It is convenient to not
be required to do unnecessary retains and autoreleases; this permits optimizations such as eliding retain/autoreleases when it can be shown
that the original pointer will still be valid at the point of return.
A method or function may be marked with __attribute__((ns_returns_autoreleased)) to indicate that it returns a pointer which is guaranteed to be
valid at least as long as the innermost autorelease pool. There are no additional semantics enforced in the definition of such a method; it merely
enables optimizations in callers.
3.2.4 Bridged casts
A bridged cast is a Cstyle cast annotated with one of three keywords:
(__bridge T) op casts the operand to the destination type T. If T is a retainable object pointer type, then op must have a nonretainable pointer
type. If T is a nonretainable pointer type, then op must have a retainable object pointer type. Otherwise the cast is illformed. There is no
transfer of ownership, and ARC inserts no retain operations.
(__bridge_retained T) op casts the operand, which must have retainable object pointer type, to the destination type, which must be a non
retainable pointer type. ARC retains the value, subject to the usual optimizations on local values, and the recipient is responsible for balancing
that +1.
(__bridge_transfer T) op casts the operand, which must have nonretainable pointer type, to the destination type, which must be a retainable
object pointer type. ARC will release the value at the end of the enclosing fullexpression, subject to the usual optimizations on local values.
These casts are required in order to transfer objects in and out of ARC control; see the rationale in the section on conversion of retainable object
pointers.
Using a __bridge_retained or __bridge_transfer cast purely to convince ARC to emit an unbalanced retain or release, respectively, is poor form.
3.3 Restrictions
3.3.1 Conversion of retainable object pointers
In general, a program which attempts to implicitly or explicitly convert a value of retainable object pointer type to any nonretainable type, or vice
versa, is illformed. For example, an ObjectiveC object pointer shall not be converted to void*. As an exception, cast to intptr_t is allowed
because such casts are not transferring ownership. The bridged casts may be used to perform these conversions where necessary.
Rationale
We cannot ensure the correct management of the lifetime of objects if they may be freely passed around as unmanaged types. The bridged
casts are provided so that the programmer may explicitly describe whether the cast transfers control into or out of ARC.
However, the following exceptions apply.
3.3.2 Conversion to retainable object pointer type of expressions with known semantics
[beginning Apple 4.0, LLVM 3.1] These exceptions have been greatly expanded; they previously applied only to a muchreduced subset which is
difficult to categorize but which included null pointers, message sends (under the given rules), and the various global constants.
An unbridged conversion to a retainable object pointer type from a type other than a retainable object pointer type is illformed, as discussed above,
unless the operand of the cast has a syntactic form which is known retained, known unretained, or known retainagnostic.
An expression is known retainagnostic if it is:
an ObjectiveC string literal,
a load from a const system global variable of C retainable pointer type, or
a null pointer constant.
clang.llvm.org/docs/AutomaticReferenceCounting.html 6/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
An expression is known unretained if it is an rvalue of C retainable pointer type and it is:
a direct call to a function, and either that function has the cf_returns_not_retained attribute or it is an audited function that does not have the
cf_returns_retained attribute and does not follow the create/copy naming convention,
a message send, and the declared method either has the cf_returns_not_retained attribute or it has neither the cf_returns_retained attribute
nor a selector family that implies a retained result, or
[beginning LLVM 3.6] a load from a const nonsystem global variable.
An expression is known retained if it is an rvalue of C retainable pointer type and it is:
a message send, and the declared method either has the cf_returns_retained attribute, or it does not have the cf_returns_not_retained
attribute but it does have a selector family that implies a retained result.
Furthermore:
a comma expression is classified according to its righthand side,
a statement expression is classified according to its result expression, if it has one,
an lvaluetorvalue conversion applied to an ObjectiveC property lvalue is classified according to the underlying message send, and
a conditional operator is classified according to its second and third operands, if they agree in classification, or else the other if one is known
retainagnostic.
If the cast operand is known retained, the conversion is treated as a __bridge_transfer cast. If the cast operand is known unretained or known
retainagnostic, the conversion is treated as a __bridge cast.
Rationale
Bridging casts are annoying. Absent the ability to completely automate the management of CF objects, however, we are left with relatively poor
attempts to reduce the need for a glut of explicit bridges. Hence these rules.
We’ve so far consciously refrained from implicitly turning retained CF results from function calls into __bridge_transfer casts. The worry is that
some code patterns — for example, creating a CF value, assigning it to an ObjCtyped local, and then calling CFRelease when done — are a bit
too likely to be accidentally accepted, leading to mysterious behavior.
For loads from const global variables of C retainable pointer type, it is reasonable to assume that global system constants were initialitzed
with true constants (e.g. string literals), but user constants might have been initialized with something dynamically allocated, using a global
initializer.
3.3.3 Conversion from retainable object pointer type in certain contexts
[beginning Apple 4.0, LLVM 3.1]
If an expression of retainable object pointer type is explicitly cast to a C retainable pointer type, the program is illformed as discussed above
unless the result is immediately used:
to initialize a parameter in an ObjectiveC message send where the parameter is not marked with the cf_consumed attribute, or
to initialize a parameter in a direct call to an audited function where the parameter is not marked with the cf_consumed attribute.
Rationale
Consumed parameters are left out because ARC would naturally balance them with a retain, which was judged too treacherous. This is in part
because several of the most common consuming functions are in the Release family, and it would be quite unfortunate for explicit releases to
be silently balanced out in this way.
4 Ownership qualification
This section describes the behavior of objects of retainable object pointer type; that is, locations in memory which store retainable object pointers.
A type is a retainable object owner type if it is a retainable object pointer type or an array type whose element type is a retainable object owner
type.
An ownership qualifier is a type qualifier which applies only to retainable object owner types. An array type is ownershipqualified according to its
element type, and adding an ownership qualifier to an array type so qualifies its element type.
A program is illformed if it attempts to apply an ownership qualifier to a type which is already ownershipqualified, even if it is the same qualifier.
There is a single exception to this rule: an ownership qualifier may be applied to a substituted template type parameter, which overrides the
ownership qualifier provided by the template argument.
When forming a function type, the result type is adjusted so that any toplevel ownership qualifier is deleted.
clang.llvm.org/docs/AutomaticReferenceCounting.html 7/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
Except as described under the inference rules, a program is illformed if it attempts to form a pointer or reference type to a retainable object owner
type which lacks an ownership qualifier.
Rationale
These rules, together with the inference rules, ensure that all objects and lvalues of retainable object pointer type have an ownership qualifier.
The ability to override an ownership qualifier during template substitution is required to counteract the inference of __strong for template
type arguments. Ownership qualifiers on return types are dropped because they serve no purpose there except to cause spurious problems
with overloading and templates.
There are four ownership qualifiers:
__autoreleasing
__strong
__unsafe_unretained
__weak
A type is nontrivially ownershipqualified if it is qualified with __autoreleasing, __strong, or __weak.
4.1 Spelling
The names of the ownership qualifiers are reserved for the implementation. A program may not assume that they are or are not implemented with
macros, or what those macros expand to.
An ownership qualifier may be written anywhere that any other type qualifier may be written.
If an ownership qualifier appears in the declarationspecifiers, the following rules apply:
if the type specifier is a retainable object owner type, the qualifier initially applies to that type;
otherwise, if the outermost nonarray declarator is a pointer or block pointer declarator, the qualifier initially applies to that type;
otherwise the program is illformed.
If the qualifier is so applied at a position in the declaration where the nextinnermost declarator is a function declarator, and there is an block
declarator within that function declarator, then the qualifier applies instead to that block declarator and this rule is considered afresh beginning
from the new position.
If an ownership qualifier appears on the declarator name, or on the declared object, it is applied to the innermost pointer or blockpointer type.
If an ownership qualifier appears anywhere else in a declarator, it applies to the type there.
Rationale
Ownership qualifiers are like const and volatile in the sense that they may sensibly apply at multiple distinct positions within a declarator.
However, unlike those qualifiers, there are many situations where they are not meaningful, and so we make an effort to “move” the qualifier to a
place where it will be meaningful. The general goal is to allow the programmer to write, say, __strong before the entire declaration and have it
apply in the leftmost sensible place.
4.1.1 Property declarations
A property of retainable object pointer type may have ownership. If the property’s type is ownershipqualified, then the property has that ownership.
If the property has one of the following modifiers, then the property has the corresponding ownership. A property is illformed if it has conflicting
sources of ownership, or if it has redundant ownership modifiers, or if it has __autoreleasing ownership.
assign implies __unsafe_unretained ownership.
copy implies __strong ownership, as well as the usual behavior of copy semantics on the setter.
retain implies __strong ownership.
strong implies __strong ownership.
unsafe_unretained implies __unsafe_unretained ownership.
weak implies __weak ownership.
With the exception of weak, these modifiers are available in nonARC modes.
A property’s specified ownership is preserved in its metadata, but otherwise the meaning is purely conventional unless the property is synthesized. If
a property is synthesized, then the associated instance variable is the instance variable which is named, possibly implicitly, by the @synthesize
declaration. If the associated instance variable already exists, then its ownership qualification must equal the ownership of the property; otherwise,
the instance variable is created with that ownership qualification.
A property of retainable object pointer type which is synthesized without a source of ownership has the ownership of its associated instance
variable, if it already exists; otherwise, [beginning Apple 3.1, LLVM 3.1] its ownership is implicitly strong. Prior to this revision, it was illformed to
clang.llvm.org/docs/AutomaticReferenceCounting.html 8/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
synthesize such a property.
Rationale
Using strong by default is safe and consistent with the generic ARC rule about inferring ownership. It is, unfortunately, inconsistent with the
nonARC rule which states that such properties are implicitly assign. However, that rule is clearly untenable in ARC, since it leads to default
unsafe code. The main merit to banning the properties is to avoid confusion with nonARC practice, which did not ultimately strike us as
sufficient to justify requiring extra syntax and (more importantly) forcing novices to understand ownership rules just to declare a property when
the default is so reasonable. Changing the rule away from nonARC practice was acceptable because we had conservatively banned the
synthesis in order to give ourselves exactly this leeway.
Applying __attribute__((NSObject)) to a property not of retainable object pointer type has the same behavior it does outside of ARC: it requires the
property type to be some sort of pointer and permits the use of modifiers other than assign. These modifiers only affect the synthesized getter and
setter; direct accesses to the ivar (even if synthesized) still have primitive semantics, and the value in the ivar will not be automatically released
during deallocation.
4.2 Semantics
There are five managed operations which may be performed on an object of retainable object pointer type. Each qualifier specifies different
semantics for each of these operations. It is still undefined behavior to access an object outside of its lifetime.
A load or store with “primitive semantics” has the same semantics as the respective operation would have on an void* lvalue with the same
alignment and nonownership qualification.
Reading occurs when performing a lvaluetorvalue conversion on an object lvalue.
For __weak objects, the current pointee is retained and then released at the end of the current fullexpression. This must execute atomically with
respect to assignments and to the final release of the pointee.
For all other objects, the lvalue is loaded with primitive semantics.
Assignment occurs when evaluating an assignment operator. The semantics vary based on the qualification:
For __strong objects, the new pointee is first retained; second, the lvalue is loaded with primitive semantics; third, the new pointee is stored into
the lvalue with primitive semantics; and finally, the old pointee is released. This is not performed atomically; external synchronization must be
used to make this safe in the face of concurrent loads and stores.
For __weak objects, the lvalue is updated to point to the new pointee, unless the new pointee is an object currently undergoing deallocation, in
which case the lvalue is updated to a null pointer. This must execute atomically with respect to other assignments to the object, to reads from
the object, and to the final release of the new pointee.
For __unsafe_unretained objects, the new pointee is stored into the lvalue using primitive semantics.
For __autoreleasing objects, the new pointee is retained, autoreleased, and stored into the lvalue using primitive semantics.
Initialization occurs when an object’s lifetime begins, which depends on its storage duration. Initialization proceeds in two stages:
1. First, a null pointer is stored into the lvalue using primitive semantics. This step is skipped if the object is __unsafe_unretained.
2. Second, if the object has an initializer, that expression is evaluated and then assigned into the object using the usual assignment semantics.
Destruction occurs when an object’s lifetime ends. In all cases it is semantically equivalent to assigning a null pointer to the object, with the proviso
that of course the object cannot be legally read after the object’s lifetime ends.
Moving occurs in specific situations where an lvalue is “moved from”, meaning that its current pointee will be used but the object may be left in a
different (but still valid) state. This arises with __block variables and rvalue references in C++. For __strong lvalues, moving is equivalent to loading
the lvalue with primitive semantics, writing a null pointer to it with primitive semantics, and then releasing the result of the load at the end of the
current fullexpression. For all other lvalues, moving is equivalent to reading the object.
4.3 Restrictions
4.3.1 Weakunavailable types
It is explicitly permitted for ObjectiveC classes to not support __weak references. It is undefined behavior to perform an operation with weak
assignment semantics with a pointer to an ObjectiveC object whose class does not support __weak references.
Rationale
Historically, it has been possible for a class to provide its own referencecount implementation by overriding retain, release, etc. However,
weak references to an object require coordination with its class’s referencecount implementation because, among other things, weak loads
and stores must be atomic with respect to the final release. Therefore, existing custom referencecount implementations will generally not
support weak references without additional effort. This is unavoidable without breaking binary compatibility.
clang.llvm.org/docs/AutomaticReferenceCounting.html 9/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
A class may indicate that it does not support weak references by providing the objc_arc_weak_reference_unavailable attribute on the class’s
interface declaration. A retainable object pointer type is weakunavailable if is a pointer to an (optionally protocolqualified) ObjectiveC class T
where T or one of its superclasses has the objc_arc_weak_reference_unavailable attribute. A program is illformed if it applies the __weak ownership
qualifier to a weakunavailable type or if the value operand of a weak assignment operation has a weakunavailable type.
4.3.2 Storage duration of __autoreleasing objects
A program is illformed if it declares an __autoreleasing object of nonautomatic storage duration. A program is illformed if it captures an
__autoreleasing object in a block or, unless by reference, in a C++11 lambda.
Rationale
Autorelease pools are tied to the current thread and scope by their nature. While it is possible to have temporary objects whose instance
variables are filled with autoreleased objects, there is no way that ARC can provide any sort of safety guarantee there.
It is undefined behavior if a nonnull pointer is assigned to an __autoreleasing object while an autorelease pool is in scope and then that object is
read after the autorelease pool’s scope is left.
4.3.3 Conversion of pointers to ownershipqualified types
A program is illformed if an expression of type T* is converted, explicitly or implicitly, to the type U*, where T and U have different ownership
qualification, unless:
T is qualified with __strong, __autoreleasing, or __unsafe_unretained, and U is qualified with both const and __unsafe_unretained; or
either T or U is cv void, where cv is an optional sequence of nonownership qualifiers; or
the conversion is requested with a reinterpret_cast in ObjectiveC++; or
the conversion is a wellformed passbywriteback.
The analogous rule applies to T& and U& in ObjectiveC++.
Rationale
These rules provide a reasonable level of typesafety for indirect pointers, as long as the underlying memory is not deallocated. The conversion
to const __unsafe_unretained is permitted because the semantics of reads are equivalent across all these ownership semantics, and that’s a
very useful and common pattern. The interconversion with void* is useful for allocating memory or otherwise escaping the type system, but use
it carefully. reinterpret_cast is considered to be an obvious enough sign of taking responsibility for any problems.
It is undefined behavior to access an ownershipqualified object through an lvalue of a differentlyqualified type, except that any non__weak object
may be read through an __unsafe_unretained lvalue.
It is undefined behavior if the storage of a __strong or __weak object is not properly initialized before the first managed operation is performed on the
object, or if the storage of such an object is freed or reused before the object has been properly deinitialized. Storage for a __strong or __weak object
may be properly initialized by filling it with the representation of a null pointer, e.g. by acquiring the memory with calloc or using bzero to zero it out.
A __strong or __weak object may be properly deinitialized by assigning a null pointer into it. A __strong object may also be properly initialized by
copying into it (e.g. with memcpy) the representation of a different __strong object whose storage has been properly initialized; doing this properly
deinitializes the source object and causes its storage to no longer be properly initialized. A __weak object may not be representationcopied in this
way.
These requirements are followed automatically for objects whose initialization and deinitialization are under the control of ARC:
objects of static, automatic, and temporary storage duration
instance variables of ObjectiveC objects
elements of arrays where the array object’s initialization and deinitialization are under the control of ARC
fields of ObjectiveC struct types where the struct object’s initialization and deinitialization are under the control of ARC
nonstatic data members of ObjectiveC++ nonunion class types
ObjectiveC++ objects and arrays of dynamic storage duration created with the new or new[] operators and destroyed with the corresponding
delete or delete[] operator
They are not followed automatically for these objects:
objects of dynamic storage duration created in other memory, such as that returned by malloc
union members
Rationale
ARC must perform special operations when initializing an object and when destroying it. In many common situations, ARC knows when an
object is created and when it is destroyed and can ensure that these operations are performed correctly. Otherwise, however, ARC requires
clang.llvm.org/docs/AutomaticReferenceCounting.html 10/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
programmer cooperation to establish its initialization invariants because it is infeasible for ARC to dynamically infer whether they are intact. For
example, there is no syntactic difference in C between an assignment that is intended by the programmer to initialize a variable and one that is
intended to replace the existing value stored there, but ARC must perform one operation or the other. ARC chooses to always assume that
objects are initialized (except when it is in charge of initializing them) because the only workable alternative would be to ban all code patterns
that could potentially be used to access uninitialized memory, and that would be too limiting. In practice, this is rarely a problem because
programmers do not generally need to work with objects for which the requirements are not handled automatically.
Note that dynamicallyallocated ObjectiveC++ arrays of nontriviallyownershipqualified type are not ABIcompatible with nonARC code because
the nonARC code will consider the element type to be POD. Such arrays that are new[]’d in ARC translation units cannot be delete[]’d in nonARC
translation units and viceversa.
4.3.4 Passing to an out parameter by writeback
If the argument passed to a parameter of type T __autoreleasing * has type U oq *, where oq is an ownership qualifier, then the argument is a
candidate for passbywriteback` if:
oq is __strong or __weak, and
it would be legal to initialize a T __strong * with a U __strong *.
For purposes of overload resolution, an implicit conversion sequence requiring a passbywriteback is always worse than an implicit conversion
sequence not requiring a passbywriteback.
The passbywriteback is illformed if the argument expression does not have a legal form:
&var, where var is a scalar variable of automatic storage duration with retainable object pointer type
a conditional expression where the second and third operands are both legal forms
a cast whose operand is a legal form
a null pointer constant
Rationale
The restriction in the form of the argument serves two purposes. First, it makes it impossible to pass the address of an array to the argument,
which serves to protect against an otherwise serious risk of misinferring an “array” argument as an outparameter. Second, it makes it much
less likely that the user will see confusing aliasing problems due to the implementation, below, where their store to the writeback temporary is
not immediately seen in the original argument variable.
A passbywriteback is evaluated as follows:
1. The argument is evaluated to yield a pointer p of type U oq *.
2. If p is a null pointer, then a null pointer is passed as the argument, and no further work is required for the passbywriteback.
3. Otherwise, a temporary of type T __autoreleasing is created and initialized to a null pointer.
4. If the parameter is not an ObjectiveC method parameter marked out, then *p is read, and the result is written into the temporary with primitive
semantics.
5. The address of the temporary is passed as the argument to the actual call.
6. After the call completes, the temporary is loaded with primitive semantics, and that value is assigned into *p.
Rationale
This is all admittedly convoluted. In an ideal world, we would see that a local variable is being passed to an outparameter and retroactively
modify its type to be __autoreleasing rather than __strong. This would be remarkably difficult and not always wellfounded under the C type
system. However, it was judged unacceptably invasive to require programmers to write __autoreleasing on all the variables they intend to use
for outparameters. This was the least bad solution.
4.3.5 Ownershipqualified fields of structs and unions
A program is illformed if it declares a member of a C struct or union to have a nontrivially ownershipqualified type.
Rationale
The resulting type would be nonPOD in the C++ sense, but C does not give us very good language tools for managing the lifetime of
aggregates, so it is more convenient to simply forbid them. It is still possible to manage this with a void* or an __unsafe_unretained object.
This restriction does not apply in ObjectiveC++. However, nontrivally ownershipqualified types are considered nonPOD: in C++11 terms, they are
not trivially default constructible, copy constructible, move constructible, copy assignable, move assignable, or destructible. It is a violation of C++’s
One Definition Rule to use a class outside of ARC that, under ARC, would have a nontrivially ownershipqualified member.
clang.llvm.org/docs/AutomaticReferenceCounting.html 11/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
Rationale
Unlike in C, we can express all the necessary ARC semantics for ownershipqualified subobjects as suboperations of the (default) special
member functions for the class. These functions then become nontrivial. This has the nonobvious result that the class will have a nontrivial
copy constructor and nontrivial destructor; if this would not normally be true outside of ARC, objects of the type will be passed and returned in
an ABIincompatible manner.
4.4 Ownership inference
4.4.1 Objects
If an object is declared with retainable object owner type, but without an explicit ownership qualifier, its type is implicitly adjusted to have __strong
qualification.
As a special case, if the object’s base type is Class (possibly protocolqualified), the type is adjusted to have __unsafe_unretained qualification
instead.
4.4.2 Indirect parameters
If a function or method parameter has type T*, where T is an ownershipunqualified retainable object pointer type, then:
if T is constqualified or Class, then it is implicitly qualified with __unsafe_unretained;
otherwise, it is implicitly qualified with __autoreleasing.
Rationale
__autoreleasing exists mostly for this case, the Cocoa convention for outparameters. Since a pointer to const is obviously not an out
parameter, we instead use a type more useful for passing arrays. If the user instead intends to pass in a mutable array, inferring
__autoreleasing is the wrong thing to do; this directs some of the caution in the following rules about writeback.
Such a type written anywhere else would be illformed by the general rule requiring ownership qualifiers.
This rule does not apply in ObjectiveC++ if a parameter’s type is dependent in a template pattern and is only instantiated to a type which would be
a pointer to an unqualified retainable object pointer type. Such code is still illformed.
Rationale
The convention is very unlikely to be intentional in template code.
4.4.3 Template arguments
If a template argument for a template type parameter is an retainable object owner type that does not have an explicit ownership qualifier, it is
adjusted to have __strong qualification. This adjustment occurs regardless of whether the template argument was deduced or explicitly specified.
Rationale
__strong is a useful default for containers (e.g., std::vector<id>), which would otherwise require explicit qualification. Moreover, unqualified
retainable object pointer types are unlikely to be useful within templates, since they generally need to have a qualifier applied to the before
being used.
5 Method families
An ObjectiveC method may fall into a method family, which is a conventional set of behaviors ascribed to it by the Cocoa conventions.
A method is in a certain method family if:
it has a objc_method_family attribute placing it in that family; or if not that,
it does not have an objc_method_family attribute placing it in a different or no family, and
its selector falls into the corresponding selector family, and
its signature obeys the added restrictions of the method family.
A selector is in a certain selector family if, ignoring any leading underscores, the first component of the selector either consists entirely of the name
of the method family or it begins with that name followed by a character other than a lowercase letter. For example, _perform:with: and
clang.llvm.org/docs/AutomaticReferenceCounting.html 12/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
performWith: would fall into the perform family (if we recognized one), but performing:with would not.
The families and their added restrictions are:
alloc methods must return a retainable object pointer type.
copy methods must return a retainable object pointer type.
mutableCopy methods must return a retainable object pointer type.
new methods must return a retainable object pointer type.
init methods must be instance methods and must return an ObjectiveC pointer type. Additionally, a program is illformed if it declares or
contains a call to an init method whose return type is neither id nor a pointer to a superclass or subclass of the declaring class (if the method
was declared on a class) or the static receiver type of the call (if it was declared on a protocol).
Rationale
There are a fair number of existing methods with initlike selectors which nonetheless don’t follow the init conventions. Typically these
are either accidental naming collisions or helper methods called during initialization. Because of the peculiar retain/release behavior of
init methods, it’s very important not to treat these methods as init methods if they aren’t meant to be. It was felt that implicitly defining
these methods out of the family based on the exact relationship between the return type and the declaring class would be much too subtle
and fragile. Therefore we identify a small number of legitimateseeming return types and call everything else an error. This serves the
secondary purpose of encouraging programmers not to accidentally give methods names in the init family.
Note that a method with an initfamily selector which returns a nonObjectiveC type (e.g. void) is perfectly wellformed; it simply isn’t in
the init family.
A program is illformed if a method’s declarations, implementations, and overrides do not all have the same method family.
5.1 Explicit method family control
A method may be annotated with the objc_method_family attribute to precisely control which method family it belongs to. If a method in an
@implementation does not have this attribute, but there is a method declared in the corresponding @interface that does, then the attribute is copied
to the declaration in the @implementation. The attribute is available outside of ARC, and may be tested for with the preprocessor query
__has_attribute(objc_method_family).
The attribute is spelled __attribute__((objc_method_family( family ))). If family is none, the method has no family, even if it would otherwise be
considered to have one based on its selector and type. Otherwise, family must be one of alloc, copy, init, mutableCopy, or new, in which case the
method is considered to belong to the corresponding family regardless of its selector. It is an error if a method that is explicitly added to a family in
this way does not meet the requirements of the family other than the selector naming convention.
Rationale
The rules codified in this document describe the standard conventions of ObjectiveC. However, as these conventions have not heretofore
been enforced by an unforgiving mechanical system, they are only imperfectly kept, especially as they haven’t always even been precisely
defined. While it is possible to define lowlevel ownership semantics with attributes like ns_returns_retained, this attribute allows the user to
communicate semantic intent, which is of use both to ARC (which, e.g., treats calls to init specially) and the static analyzer.
5.2 Semantics of method families
A method’s membership in a method family may imply nonstandard semantics for its parameters and return type.
Methods in the alloc, copy, mutableCopy, and new families — that is, methods in all the currentlydefined families except init — implicitly return a
retained object as if they were annotated with the ns_returns_retained attribute. This can be overridden by annotating the method with either of
the ns_returns_autoreleased or ns_returns_not_retained attributes.
Properties also follow same naming rules as methods. This means that those in the alloc, copy, mutableCopy, and new families provide access to
retained objects. This can be overridden by annotating the property with ns_returns_not_retained attribute.
5.2.1 Semantics of init
Methods in the init family implicitly consume their self parameter and return a retained object. Neither of these properties can be altered
through attributes.
A call to an init method with a receiver that is either self (possibly parenthesized or casted) or super is called a delegate init call. It is an error for
a delegate init call to be made except from an init method, and excluding blocks within such methods.
clang.llvm.org/docs/AutomaticReferenceCounting.html 13/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
As an exception to the usual rule, the variable self is mutable in an init method and has the usual semantics for a __strong variable. However, it
is undefined behavior and the program is illformed, no diagnostic required, if an init method attempts to use the previous value of self after the
completion of a delegate init call. It is conventional, but not required, for an init method to return self.
It is undefined behavior for a program to cause two or more calls to init methods on the same object, except that each init method invocation may
perform at most one delegate init call.
5.2.2 Related result types
Certain methods are candidates to have related result types:
class methods in the alloc and new method families
instance methods in the init family
the instance method self
outside of ARC, the instance methods retain and autorelease
If the formal result type of such a method is id or protocolqualified id, or a type equal to the declaring class or a superclass, then it is said to have a
related result type. In this case, when invoked in an explicit message send, it is assumed to return a type related to the type of the receiver:
if it is a class method, and the receiver is a class name T, the message send expression has type T*; otherwise
if it is an instance method, and the receiver has type T, the message send expression has type T; otherwise
the message send expression has the normal result type of the method.
This is a new rule of the ObjectiveC language and applies outside of ARC.
Rationale
ARC’s automatic code emission is more prone than most code to signature errors, i.e. errors where a call was emitted against one method
signature, but the implementing method has an incompatible signature. Having more precise type information helps drastically lower this risk,
as well as catching a number of latent bugs.
6 Optimization
Within this section, the word function will be used to refer to any structured unit of code, be it a C function, an ObjectiveC method, or a block.
This specification describes ARC as performing specific retain and release operations on retainable object pointers at specific points during the
execution of a program. These operations make up a noncontiguous subsequence of the computation history of the program. The portion of this
sequence for a particular retainable object pointer for which a specific function execution is directly responsible is the formal local retain history of
the object pointer. The corresponding actual sequence executed is the dynamic local retain history.
However, under certain circumstances, ARC is permitted to reorder and eliminate operations in a manner which may alter the overall computation
history beyond what is permitted by the general “as if” rule of C/C++ and the restrictions on the implementation of retain and release.
Rationale
Specifically, ARC is sometimes permitted to optimize release operations in ways which might cause an object to be deallocated before it would
otherwise be. Without this, it would be almost impossible to eliminate any retain/release pairs. For example, consider the following code:
id x = _ivar;
[x foo];
If we were not permitted in any event to shorten the lifetime of the object in x, then we would not be able to eliminate this retain and release
unless we could prove that the message send could not modify _ivar (or deallocate self). Since message sends are opaque to the optimizer,
this is not possible, and so ARC’s hands would be almost completely tied.
ARC makes no guarantees about the execution of a computation history which contains undefined behavior. In particular, ARC makes no
guarantees in the presence of race conditions.
ARC may assume that any retainable object pointers it receives or generates are instantaneously valid from that point until a point which, by the
concurrency model of the host language, happensafter the generation of the pointer and happensbefore a release of that object (possibly via an
aliasing pointer or indirectly due to destruction of a different object).
Rationale
There is very little point in trying to guarantee correctness in the presence of race conditions. ARC does not have a stackscanning garbage
collector, and guaranteeing the atomicity of every load and store operation would be prohibitive and preclude a vast amount of optimization.
clang.llvm.org/docs/AutomaticReferenceCounting.html 14/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
ARC may assume that nonARC code engages in sensible balancing behavior and does not rely on exact or minimum retain count values except as
guaranteed by __strong object invariants or +1 transfer conventions. For example, if an object is provably doubleretained and doublereleased,
ARC may eliminate the inner retain and release; it does not need to guard against code which performs an unbalanced release followed by a
“balancing” retain.
6.1 Object liveness
ARC may not allow a retainable object X to be deallocated at a time T in a computation history if:
X is the value stored in a __strong object S with precise lifetime semantics, or
X is the value stored in a __strong object S with imprecise lifetime semantics and, at some point after T but before the next store to S, the
computation history features a load from S and in some way depends on the value loaded, or
X is a value described as being released at the end of the current fullexpression and, at some point after T but before the end of the full
expression, the computation history depends on that value.
Rationale
The intent of the second rule is to say that objects held in normal __strong local variables may be released as soon as the value in the variable
is no longer being used: either the variable stops being used completely or a new value is stored in the variable.
The intent of the third rule is to say that return values may be released after they’ve been used.
A computation history depends on a pointer value P if it:
performs a pointer comparison with P,
loads from P,
stores to P,
depends on a pointer value Q derived via pointer arithmetic from P (including an instancevariable or field access), or
depends on a pointer value Q loaded from P.
Dependency applies only to values derived directly or indirectly from a particular expression result and does not occur merely because a separate
pointer value dynamically aliases P. Furthermore, this dependency is not carried by values that are stored to objects.
Rationale
The restrictions on dependency are intended to make this analysis feasible by an optimizer with only incomplete information about a program.
Essentially, dependence is carried to “obvious” uses of a pointer. Merely passing a pointer argument to a function does not itself cause
dependence, but since generally the optimizer will not be able to prove that the function doesn’t depend on that parameter, it will be forced to
conservatively assume it does.
Dependency propagates to values loaded from a pointer because those values might be invalidated by deallocating the object. For example,
given the code __strong id x = p->ivar;, ARC must not move the release of p to between the load of p->ivar and the retain of that value for
storing into x.
Dependency does not propagate through stores of dependent pointer values because doing so would allow dependency to outlive the full
expression which produced the original value. For example, the address of an instance variable could be written to some global location and
then freely accessed during the lifetime of the local, or a function could return an inner pointer of an object and store it to a local. These cases
would be potentially impossible to reason about and so would basically prevent any optimizations based on imprecise lifetime. There are also
uncommon enough to make it reasonable to require the preciselifetime annotation if someone really wants to rely on them.
Dependency does propagate through return values of pointer type. The compelling source of need for this rule is a property accessor which
returns an unautoreleased result; the calling function must have the chance to operate on the value, e.g. to retain it, before ARC releases the
original pointer. Note again, however, that dependence does not survive a store, so ARC does not guarantee the continued validity of the return
value past the end of the fullexpression.
6.2 No object lifetime extension
If, in the formal computation history of the program, an object X has been deallocated by the time of an observable sideeffect, then ARC must cause
X to be deallocated by no later than the occurrence of that sideeffect, except as influenced by the reordering of the destruction of objects.
Rationale
This rule is intended to prohibit ARC from observably extending the lifetime of a retainable object, other than as specified in this document.
Together with the rule limiting the transformation of releases, this rule requires ARC to eliminate retains and release only in pairs.
ARC’s power to reorder the destruction of objects is critical to its ability to do any optimization, for essentially the same reason that it must
retain the power to decrease the lifetime of an object. Unfortunately, while it’s generally poor style for the destruction of objects to have arbitrary
clang.llvm.org/docs/AutomaticReferenceCounting.html 15/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
sideeffects, it’s certainly possible. Hence the caveat.
6.3 Precise lifetime semantics
In general, ARC maintains an invariant that a retainable object pointer held in a __strong object will be retained for the full formal lifetime of the
object. Objects subject to this invariant have precise lifetime semantics.
By default, local variables of automatic storage duration do not have precise lifetime semantics. Such objects are simply strong references which
hold values of retainable object pointer type, and these values are still fully subject to the optimizations on values under local control.
Rationale
Applying these preciselifetime semantics strictly would be prohibitive. Many useful optimizations that might theoretically decrease the lifetime
of an object would be rendered impossible. Essentially, it promises too much.
A local variable of retainable object owner type and automatic storage duration may be annotated with the objc_precise_lifetime attribute to
indicate that it should be considered to be an object with precise lifetime semantics.
Rationale
Nonetheless, it is sometimes useful to be able to force an object to be released at a precise time, even if that object does not appear to be
used. This is likely to be uncommon enough that the syntactic weight of explicitly requesting these semantics will not be burdensome, and may
even make the code clearer.
7 Miscellaneous
7.1 Special methods
7.1.1 Memory management methods
A program is illformed if it contains a method definition, message send, or @selector expression for any of the following selectors:
autorelease
release
retain
retainCount
Rationale
retainCount is banned because ARC robs it of consistent semantics. The others were banned after weighing three options for how to deal with
message sends:
Honoring them would work out very poorly if a programmer naively or accidentally tried to incorporate code written for manual retain/release
code into an ARC program. At best, such code would do twice as much work as necessary; quite frequently, however, ARC and the explicit
code would both try to balance the same retain, leading to crashes. The cost is losing the ability to perform “unrooted” retains, i.e. retains not
logically corresponding to a strong reference in the object graph.
Ignoring them would badly violate user expectations about their code. While it would make it easier to develop code simultaneously for ARC
and nonARC, there is very little reason to do so except for certain library developers. ARC and nonARC translation units share an execution
model and can seamlessly interoperate. Within a translation unit, a developer who faithfully maintains their code in nonARC mode is suffering
all the restrictions of ARC for zero benefit, while a developer who isn’t testing the nonARC mode is likely to be unpleasantly surprised if they
try to go back to it.
Banning them has the disadvantage of making it very awkward to migrate existing code to ARC. The best answer to that, given a number of
other changes and restrictions in ARC, is to provide a specialized tool to assist users in that migration.
Implementing these methods was banned because they are too integral to the semantics of ARC; many tricks which worked tolerably under
manual reference counting will misbehave if ARC performs an ephemeral extra retain or two. If absolutely required, it is still possible to
implement them in nonARC code, for example in a category; the implementations must obey the semantics laid out elsewhere in this
document.
7.1.2 dealloc
clang.llvm.org/docs/AutomaticReferenceCounting.html 16/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
A program is illformed if it contains a message send or @selector expression for the selector dealloc.
Rationale
There are no legitimate reasons to call dealloc directly.
A class may provide a method definition for an instance method named dealloc. This method will be called after the final release of the object but
before it is deallocated or any of its instance variables are destroyed. The superclass’s implementation of dealloc will be called automatically when
the method returns.
Rationale
Even though ARC destroys instance variables automatically, there are still legitimate reasons to write a dealloc method, such as freeing non
retainable resources. Failing to call [super dealloc] in such a method is nearly always a bug. Sometimes, the object is simply trying to prevent
itself from being destroyed, but dealloc is really far too late for the object to be raising such objections. Somewhat more legitimately, an object
may have been poolallocated and should not be deallocated with free; for now, this can only be supported with a dealloc implementation
outside of ARC. Such an implementation must be very careful to do all the other work that NSObject’s dealloc would, which is outside the scope
of this document to describe.
The instance variables for an ARCcompiled class will be destroyed at some point after control enters the dealloc method for the root class of the
class. The ordering of the destruction of instance variables is unspecified, both within a single class and between subclasses and superclasses.
Rationale
The traditional, nonARC pattern for destroying instance variables is to destroy them immediately before calling [super dealloc]. Unfortunately,
message sends from the superclass are quite capable of reaching methods in the subclass, and those methods may well read or write to those
instance variables. Making such message sends from dealloc is generally discouraged, since the subclass may well rely on other invariants
that were broken during dealloc, but it’s not so inescapably dangerous that we felt comfortable calling it undefined behavior. Therefore we
chose to delay destroying the instance variables to a point at which message sends are clearly disallowed: the point at which the root class’s
deallocation routines take over.
In most code, the difference is not observable. It can, however, be observed if an instance variable holds a strong reference to an object whose
deallocation will trigger a sideeffect which must be carefully ordered with respect to the destruction of the super class. Such code violates the
design principle that semantically important behavior should be explicit. A simple fix is to clear the instance variable manually during dealloc; a
more holistic solution is to move semantically important sideeffects out of dealloc and into a separate teardown phase which can rely on
working with wellformed objects.
7.2 @autoreleasepool
To simplify the use of autorelease pools, and to bring them under the control of the compiler, a new kind of statement is available in ObjectiveC. It is
written @autoreleasepool followed by a compoundstatement, i.e. by a new scope delimited by curly braces. Upon entry to this block, the current
state of the autorelease pool is captured. When the block is exited normally, whether by fallthrough or directed control flow (such as return or
break), the autorelease pool is restored to the saved state, releasing all the objects in it. When the block is exited with an exception, the pool is not
drained.
@autoreleasepool may be used in nonARC translation units, with equivalent semantics.
A program is illformed if it refers to the NSAutoreleasePool class.
Rationale
Autorelease pools are clearly important for the compiler to reason about, but it is far too much to expect the compiler to accurately reason
about control dependencies between two calls. It is also very easy to accidentally forget to drain an autorelease pool when using the manual
API, and this can significantly inflate the process’s highwatermark. The introduction of a new scope is unfortunate but basically required for
sane interaction with the rest of the language. Not draining the pool during an unwind is apparently required by the ObjectiveC exceptions
implementation.
7.3 ExternallyRetained Variables
In some situations, variables with strong ownership are considered externallyretained by the implementation. This means that the variable is
retained elsewhere, and therefore the implementation can elide retaining and releasing its value. Such a variable is implicitly const for safety. In
contrast with __unsafe_unretained, an externallyretained variable still behaves as a strong variable outside of initialization and destruction. For
instance, when an externallyretained variable is captured in a block the value of the variable is retained and released on block capture and
destruction. It also affects C++ features such as lambda capture, decltype, and template argument deduction.
clang.llvm.org/docs/AutomaticReferenceCounting.html 17/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
Implicitly, the implementation assumes that the self parameter in a noninit method and the variable in a forin loop are externallyretained.
Externallyretained semantics can also be opted into with the objc_externally_retained attribute. This attribute can apply to strong local variables,
functions, methods, or blocks:
@class WobbleAmount;
@interface Widget : NSObject
-(void)wobble:(WobbleAmount *)amount;
@end
@implementation Widget
-(void)wobble:(WobbleAmount *)amount
__attribute__((objc_externally_retained)) {
// 'amount' and 'alias' aren't retained on entry, nor released on exit.
__attribute__((objc_externally_retained)) WobbleAmount *alias = amount;
}
@end
Annotating a function with this attribute makes every parameter with strong retainable object pointer type externallyretained, unless the variable
was explicitly qualified with __strong. For instance, first_param is externallyretained (and therefore const) below, but not second_param:
__attribute__((objc_externally_retained))
void f(NSArray *first_param, __strong NSArray *second_param) {
// ...
}
You can test if your compiler has support for objc_externally_retained with __has_attribute:
#if __has_attribute(objc_externally_retained)
// Use externally retained...
#endif
7.4 self
The self parameter variable of an noninit ObjectiveC method is considered externallyretained by the implementation. It is undefined behavior, or
at least dangerous, to cause an object to be deallocated during a message send to that object. In an init method, self follows the :ref:init family
rules <arc.family.semantics.init>.
Rationale
The cost of retaining self in all methods was found to be prohibitive, as it tends to be live across calls, preventing the optimizer from proving
that the retain and release are unnecessary — for good reason, as it’s quite possible in theory to cause an object to be deallocated during its
execution without this retain and release. Since it’s extremely uncommon to actually do so, even unintentionally, and since there’s no natural
way for the programmer to remove this retain/release pair otherwise (as there is for other parameters by, say, making the variable
objc_externally_retained or qualifying it with __unsafe_unretained), we chose to make this optimizing assumption and shift some amount of
risk to the user.
7.5 Fast enumeration iteration variables
If a variable is declared in the condition of an ObjectiveC fast enumeration loop, and the variable has no explicit ownership qualifier, then it is
implicitly externallyretained so that objects encountered during the enumeration are not actually retained and released.
Rationale
This is an optimization made possible because fast enumeration loops promise to keep the objects retained during enumeration, and the
collection itself cannot be synchronously modified. It can be overridden by explicitly qualifying the variable with __strong, which will make the
variable mutable again and cause the loop to retain the objects it encounters.
7.6 Blocks
The implicit const capture variables created when evaluating a block literal expression have the same ownership semantics as the local variables
they capture. The capture is performed by reading from the captured variable and initializing the capture variable with that value; the capture
variable is destroyed when the block literal is, i.e. at the end of the enclosing scope.
clang.llvm.org/docs/AutomaticReferenceCounting.html 18/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
The inference rules apply equally to __block variables, which is a shift in semantics from nonARC, where __block variables did not implicitly retain
during capture.
__block variables of retainable object owner type are moved off the stack by initializing the heap copy with the result of moving from the stack copy.
With the exception of retains done as part of initializing a __strong parameter variable or reading a __weak variable, whenever these semantics call
for retaining a value of blockpointer type, it has the effect of a Block_copy. The optimizer may remove such copies when it sees that the result is
used only as an argument to a call.
7.7 Exceptions
By default in Objective C, ARC is not exceptionsafe for normal releases:
It does not end the lifetime of __strong variables when their scopes are abnormally terminated by an exception.
It does not perform releases which would occur at the end of a fullexpression if that fullexpression throws an exception.
A program may be compiled with the option -fobjc-arc-exceptions in order to enable these, or with the option -fno-objc-arc-exceptions to
explicitly disable them, with the last such argument “winning”.
Rationale
The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code
exceptionssafe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions
safety. Therefore, ARCgenerated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated
anyway. Programs which do care about recovering from exceptions should enable the option.
In ObjectiveC++, -fobjc-arc-exceptions is enabled by default.
Rationale
C++ already introduces pervasive exceptionscleanup code of the sort that ARC introduces. C++ programmers who have not already disabled
exceptions are much more likely to actual require exceptionsafety.
ARC does end the lifetimes of __weak objects when an exception terminates their scope unless exceptions are disabled in the compiler.
Rationale
The consequence of a local __weak object not being destroyed is very likely to be corruption of the ObjectiveC runtime, so we want to be safer
here. Of course, potentially massive leaks are about as likely to take down the process as this corruption is if the program does try to recover
from exceptions.
7.8 Interior pointers
An ObjectiveC method returning a nonretainable pointer may be annotated with the objc_returns_inner_pointer attribute to indicate that it returns
a handle to the internal data of an object, and that this reference will be invalidated if the object is destroyed. When such a message is sent to an
object, the object’s lifetime will be extended until at least the earliest of:
the last use of the returned pointer, or any pointer derived from it, in the calling function or
the autorelease pool is restored to a previous state.
Rationale
Rationale: not all memory and resources are managed with reference counts; it is common for objects to manage private resources in their
own, private way. Typically these resources are completely encapsulated within the object, but some classes offer their users direct access for
efficiency. If ARC is not aware of methods that return such “interior” pointers, its optimizations can cause the owning object to be reclaimed too
soon. This attribute informs ARC that it must tread lightly.
The extension rules are somewhat intentionally vague. The autorelease pool limit is there to permit a simple implementation to simply retain
and autorelease the receiver. The other limit permits some amount of optimization. The phrase “derived from” is intended to encompass the
results both of pointer transformations, such as casts and arithmetic, and of loading from such derived pointers; furthermore, it applies whether
or not such derivations are applied directly in the calling code or by other utility code (for example, the C library routine strchr). However, the
implementation never need account for uses after a return from the code which calls the method returning an interior pointer.
As an exception, no extension is required if the receiver is loaded directly from a __strong object with precise lifetime semantics.
clang.llvm.org/docs/AutomaticReferenceCounting.html 19/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
Rationale
Implicit autoreleases carry the risk of significantly inflating memory use, so it’s important to provide users a way of avoiding these autoreleases.
Tying this to precise lifetime semantics is ideal, as for local variables this requires a very explicit annotation, which allows ARC to trust the user
with good cheer.
7.9 C retainable pointer types
A type is a C retainable pointer type if it is a pointer to (possibly qualified) void or a pointer to a (possibly qualifier) struct or class type.
Rationale
ARC does not manage pointers of CoreFoundation type (or any of the related families of retainable C pointers which interoperate with
ObjectiveC for retain/release operation). In fact, ARC does not even know how to distinguish these types from arbitrary C pointer types. The
intent of this concept is to filter out some obviously nonobject types while leaving a hook for later tightening if a means of exhaustively marking
CF types is made available.
7.9.1 Auditing of C retainable pointer interfaces
[beginning Apple 4.0, LLVM 3.1]
A C function may be marked with the cf_audited_transfer attribute to express that, except as otherwise marked with attributes, it obeys the
parameter (consuming vs. nonconsuming) and return (retained vs. nonretained) conventions for a C function of its name, namely:
A parameter of C retainable pointer type is assumed to not be consumed unless it is marked with the cf_consumed attribute, and
A result of C retainable pointer type is assumed to not be returned retained unless the function is either marked cf_returns_retained or it
follows the create/copy naming convention and is not marked cf_returns_not_retained.
A function obeys the create/copy naming convention if its name contains as a substring:
either “Create” or “Copy” not followed by a lowercase letter, or
either “create” or “copy” not followed by a lowercase letter and not preceded by any letter, whether uppercase or lowercase.
A second attribute, cf_unknown_transfer, signifies that a function’s transfer semantics cannot be accurately captured using any of these annotations.
A program is illformed if it annotates the same function with both cf_audited_transfer and cf_unknown_transfer.
A pragma is provided to facilitate the mass annotation of interfaces:
#pragma clang arc_cf_code_audited begin
...
#pragma clang arc_cf_code_audited end
All C functions declared within the extent of this pragma are treated as if annotated with the cf_audited_transfer attribute unless they otherwise
have the cf_unknown_transfer attribute. The pragma is accepted in all language modes. A program is illformed if it attempts to change files,
whether by including a file or ending the current file, within the extent of this pragma.
It is possible to test for all the features in this section with __has_feature(arc_cf_code_audited).
Rationale
A significant inconvenience in ARC programming is the necessity of interacting with APIs based around C retainable pointers. These features
are designed to make it relatively easy for API authors to quickly review and annotate their interfaces, in turn improving the fidelity of tools such
as the static analyzer and ARC. The singlefile restriction on the pragma is designed to eliminate the risk of accidentally annotating some other
header’s interfaces.
8 Runtime support
This section describes the interaction between the ARC runtime and the code generated by the ARC compiler. This is not part of the ARC language
specification; instead, it is effectively a languagespecific ABI supplement, akin to the “Itanium” generic ABI for C++.
Ownership qualification does not alter the storage requirements for objects, except that it is undefined behavior if a __weak object is inadequately
aligned for an object of type id. The other qualifiers may be used on explicitly underaligned memory.
The runtime tracks __weak objects which holds nonnull values. It is undefined behavior to direct modify a __weak object which is being tracked by the
runtime except through an objc_storeWeak, objc_destroyWeak, or objc_moveWeak call.
clang.llvm.org/docs/AutomaticReferenceCounting.html 20/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
The runtime must provide a number of new entrypoints which the compiler may emit, which are described in the remainder of this section.
Rationale
Several of these functions are semantically equivalent to a message send; we emit calls to C functions instead because:
the machine code to do so is significantly smaller,
it is much easier to recognize the C functions in the ARC optimizer, and
a sufficient sophisticated runtime may be able to avoid the message send in common cases.
Several other of these functions are “fused” operations which can be described entirely in terms of other operations. We use the fused
operations primarily as a codesize optimization, although in some cases there is also a real potential for avoiding redundant operations in the
runtime.
8.1 id objc_autorelease(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it adds the object to the innermost autorelease pool exactly as if the object had been sent the
autorelease message.
Always returns value.
8.2 void objc_autoreleasePoolPop(void *pool);
Precondition: pool is the result of a previous call to objc_autoreleasePoolPush on the current thread, where neither pool nor any enclosing pool
have previously been popped.
Releases all the objects added to the given autorelease pool and any autorelease pools it encloses, then sets the current autorelease pool to the
pool directly enclosing pool.
8.3 void *objc_autoreleasePoolPush(void);
Creates a new autorelease pool that is enclosed by the current pool, makes that the current pool, and returns an opaque “handle” to it.
Rationale
While the interface is described as an explicit hierarchy of pools, the rules allow the implementation to just keep a stack of objects, using the
stack depth as the opaque pool handle.
8.4 id objc_autoreleaseReturnValue(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it makes a best effort to hand off ownership of a retain count on the object to a call to
objc_retainAutoreleasedReturnValue for the same object in an enclosing call frame. If this is not possible, the object is autoreleased as above.
Always returns value.
8.5 void objc_copyWeak(id *dest, id *src);
Precondition: src is a valid pointer which either contains a null pointer or has been registered as a __weak object. dest is a valid pointer which has
not been registered as a __weak object.
dest is initialized to be equivalent to src, potentially registering it with the runtime. Equivalent to the following code:
void objc_copyWeak(id *dest, id *src) {
objc_release(objc_initWeak(dest, objc_loadWeakRetained(src)));
}
Must be atomic with respect to calls to objc_storeWeak on src.
8.6 void objc_destroyWeak(id *object);
Precondition: object is a valid pointer which either contains a null pointer or has been registered as a __weak object.
clang.llvm.org/docs/AutomaticReferenceCounting.html 21/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
object is unregistered as a weak object, if it ever was. The current value of object is left unspecified; otherwise, equivalent to the following code:
void objc_destroyWeak(id *object) {
objc_storeWeak(object, nil);
}
Does not need to be atomic with respect to calls to objc_storeWeak on object.
8.7 id objc_initWeak(id *object, id value);
Precondition: object is a valid pointer which has not been registered as a __weak object. value is null or a pointer to a valid object.
If value is a null pointer or the object to which it points has begun deallocation, object is zeroinitialized. Otherwise, object is registered as a __weak
object pointing to value. Equivalent to the following code:
id objc_initWeak(id *object, id value) {
*object = nil;
return objc_storeWeak(object, value);
}
Returns the value of object after the call.
Does not need to be atomic with respect to calls to objc_storeWeak on object.
8.8 id objc_loadWeak(id *object);
Precondition: object is a valid pointer which either contains a null pointer or has been registered as a __weak object.
If object is registered as a __weak object, and the last value stored into object has not yet been deallocated or begun deallocation, retains and
autoreleases that value and returns it. Otherwise returns null. Equivalent to the following code:
id objc_loadWeak(id *object) {
return objc_autorelease(objc_loadWeakRetained(object));
}
Must be atomic with respect to calls to objc_storeWeak on object.
Rationale
Loading weak references would be inherently prone to race conditions without the retain.
8.9 id objc_loadWeakRetained(id *object);
Precondition: object is a valid pointer which either contains a null pointer or has been registered as a __weak object.
If object is registered as a __weak object, and the last value stored into object has not yet been deallocated or begun deallocation, retains that value
and returns it. Otherwise returns null.
Must be atomic with respect to calls to objc_storeWeak on object.
8.10 void objc_moveWeak(id *dest, id *src);
Precondition: src is a valid pointer which either contains a null pointer or has been registered as a __weak object. dest is a valid pointer which has
not been registered as a __weak object.
dest is initialized to be equivalent to src, potentially registering it with the runtime. src may then be left in its original state, in which case this call is
equivalent to objc_copyWeak, or it may be left as null.
Must be atomic with respect to calls to objc_storeWeak on src.
8.11 void objc_release(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it performs a release operation exactly as if the object had been sent the release message.
clang.llvm.org/docs/AutomaticReferenceCounting.html 22/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
8.12 id objc_retain(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it performs a retain operation exactly as if the object had been sent the retain message.
Always returns value.
8.13 id objc_retainAutorelease(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it performs a retain operation followed by an autorelease operation. Equivalent to the following
code:
id objc_retainAutorelease(id value) {
return objc_autorelease(objc_retain(value));
}
Always returns value.
8.14 id objc_retainAutoreleaseReturnValue(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it performs a retain operation followed by the operation described in
objc_autoreleaseReturnValue. Equivalent to the following code:
id objc_retainAutoreleaseReturnValue(id value) {
return objc_autoreleaseReturnValue(objc_retain(value));
}
Always returns value.
8.15 id objc_retainAutoreleasedReturnValue(id value);
Precondition: value is null or a pointer to a valid object.
If value is null, this call has no effect. Otherwise, it attempts to accept a hand off of a retain count from a call to objc_autoreleaseReturnValue on
value in a recentlycalled function or something it calls. If that fails, it performs a retain operation exactly like objc_retain.
Always returns value.
8.16 id objc_retainBlock(id value);
Precondition: value is null or a pointer to a valid block object.
If value is null, this call has no effect. Otherwise, if the block pointed to by value is still on the stack, it is copied to the heap and the address of the
copy is returned. Otherwise a retain operation is performed on the block exactly as if it had been sent the retain message.
8.17 void objc_storeStrong(id *object, id value);
Precondition: object is a valid pointer to a __strong object which is adequately aligned for a pointer. value is null or a pointer to a valid object.
Performs the complete sequence for assigning to a __strong object of nonblock type [*]. Equivalent to the following code:
void objc_storeStrong(id *object, id value) {
id oldValue = *object;
value = [value retain];
*object = value;
[oldValue release];
}
[*] This does not imply that a __strong object of block type is an invalid argument to this function. Rather it implies that an objc_retain and not
an objc_retainBlock operation will be emitted if the argument is a block.
8.18 id objc_storeWeak(id *object, id value);
clang.llvm.org/docs/AutomaticReferenceCounting.html 23/24
06/05/2019 Objective-C Automatic Reference Counting (ARC) — Clang 9 documentation
Precondition: object is a valid pointer which either contains a null pointer or has been registered as a __weak object. value is null or a pointer to a
valid object.
If value is a null pointer or the object to which it points has begun deallocation, object is assigned null and unregistered as a __weak object.
Otherwise, object is registered as a __weak object or has its registration updated to point to value.
Returns the value of object after the call.
clang.llvm.org/docs/AutomaticReferenceCounting.html 24/24
You might also like
- Mastering Object-Oriented Programming with Python: Unlock the Secrets of Expert-Level SkillsFrom EverandMastering Object-Oriented Programming with Python: Unlock the Secrets of Expert-Level SkillsNo ratings yet
- Learn Professional Programming in .Net Using C#, Visual Basic, and Asp.NetFrom EverandLearn Professional Programming in .Net Using C#, Visual Basic, and Asp.NetNo ratings yet
- Python Decorators in Depth: Definitive Reference for Developers and EngineersFrom EverandPython Decorators in Depth: Definitive Reference for Developers and EngineersNo ratings yet
- The Comprehensive Guide to Kotlin Programming : A Complete Reference GuideFrom EverandThe Comprehensive Guide to Kotlin Programming : A Complete Reference GuideNo ratings yet
- Mastering Generic Programming in C++: Unlock the Secrets of Expert-Level SkillsFrom EverandMastering Generic Programming in C++: Unlock the Secrets of Expert-Level SkillsNo ratings yet
- Django Unleashed: Building Web Applications with Python's FrameworkFrom EverandDjango Unleashed: Building Web Applications with Python's FrameworkNo ratings yet
- C++ Basics for New Programmers: A Practical Guide with ExamplesFrom EverandC++ Basics for New Programmers: A Practical Guide with ExamplesNo ratings yet
- Modular Programming with JavaScript: Modularize your JavaScript code for better readability, greater maintainability, and enhanced testabilityFrom EverandModular Programming with JavaScript: Modularize your JavaScript code for better readability, greater maintainability, and enhanced testabilityNo ratings yet
- Objective-C Language Reference and Techniques: Definitive Reference for Developers and EngineersFrom EverandObjective-C Language Reference and Techniques: Definitive Reference for Developers and EngineersNo ratings yet
- Machine Learning in the AWS Cloud: Add Intelligence to Applications with Amazon SageMaker and Amazon RekognitionFrom EverandMachine Learning in the AWS Cloud: Add Intelligence to Applications with Amazon SageMaker and Amazon RekognitionNo ratings yet
- JavaScript Data Structures Explained: A Practical Guide with ExamplesFrom EverandJavaScript Data Structures Explained: A Practical Guide with ExamplesNo ratings yet
- C++ Advanced Programming: Building High-Performance ApplicationsFrom EverandC++ Advanced Programming: Building High-Performance ApplicationsNo ratings yet
- Mastering VB.NET: A Comprehensive Guide to Visual Basic .NET ProgrammingFrom EverandMastering VB.NET: A Comprehensive Guide to Visual Basic .NET ProgrammingNo ratings yet
- Swift Programming Simplified: A Practical Guide with ExamplesFrom EverandSwift Programming Simplified: A Practical Guide with ExamplesNo ratings yet
- Argo Workflows TemplateRef Essentials: The Complete Guide for Developers and EngineersFrom EverandArgo Workflows TemplateRef Essentials: The Complete Guide for Developers and EngineersNo ratings yet
- Java Data Structures Explained: A Practical Guide with ExampleFrom EverandJava Data Structures Explained: A Practical Guide with ExampleNo ratings yet
- Mastering Java: A Comprehensive Guide to Programming Excellence CategoryFrom EverandMastering Java: A Comprehensive Guide to Programming Excellence CategoryNo ratings yet
- Mastering the Art of C# Programming: Unraveling the Secrets of Expert-Level ProgrammingFrom EverandMastering the Art of C# Programming: Unraveling the Secrets of Expert-Level ProgrammingNo ratings yet
- Kubernetes Essentials Guide: Definitive Reference for Developers and EngineersFrom EverandKubernetes Essentials Guide: Definitive Reference for Developers and EngineersNo ratings yet
- Mastering the Art of C++ STL: Unlock the Secrets of Expert-Level SkillsFrom EverandMastering the Art of C++ STL: Unlock the Secrets of Expert-Level SkillsNo ratings yet
- The Ultimate Guide to Mastering JavaScript: A Beginner's JourneyFrom EverandThe Ultimate Guide to Mastering JavaScript: A Beginner's JourneyNo ratings yet
- C# Essentials for New Coders: A Practical Guide with ExamplesFrom EverandC# Essentials for New Coders: A Practical Guide with ExamplesNo ratings yet
- Mastering the Craft of TypeScript Programming: Unraveling the Secrets of Expert-Level ProgrammingFrom EverandMastering the Craft of TypeScript Programming: Unraveling the Secrets of Expert-Level ProgrammingNo ratings yet
- Mastering Performance Optimization in Python: Unlock the Secrets of Expert-Level SkillsFrom EverandMastering Performance Optimization in Python: Unlock the Secrets of Expert-Level SkillsNo ratings yet
- Mastering the Art of Node.js Programming: Unraveling the Secrets of Expert-Level ProgrammingFrom EverandMastering the Art of Node.js Programming: Unraveling the Secrets of Expert-Level ProgrammingNo ratings yet
- Mastering C: A Comprehensive Guide to Proficiency in The C Programming LanguageFrom EverandMastering C: A Comprehensive Guide to Proficiency in The C Programming LanguageNo ratings yet
- Introduc) On To Objec) Ve - C: Jussi Pohjolainen Tampere University of Applied SciencesNo ratings yetIntroduc) On To Objec) Ve - C: Jussi Pohjolainen Tampere University of Applied Sciences94 pages
- Stanford CS193p: Developing Applications For iOS Spring 2016No ratings yetStanford CS193p: Developing Applications For iOS Spring 201674 pages
- Method of Statement For Rental of 40ft Portable ContainerNo ratings yetMethod of Statement For Rental of 40ft Portable Container7 pages
- Lesson 7 - Simple Machines (Kinds and Safety Use)100% (1)Lesson 7 - Simple Machines (Kinds and Safety Use)22 pages
- 2004 Bombardier DS650 Repair Manual (001 121)No ratings yet2004 Bombardier DS650 Repair Manual (001 121)121 pages
- Installation Instruction of Wind Turbine-Sk - 240925 - 130523No ratings yetInstallation Instruction of Wind Turbine-Sk - 240925 - 1305232 pages
- Kohinoor Square Towera Kohinoor Square, Kohinoor Mill BuildingNo ratings yetKohinoor Square Towera Kohinoor Square, Kohinoor Mill Building5 pages
- H01P Handy Polaris Brochure GB 2014 041 PDFNo ratings yetH01P Handy Polaris Brochure GB 2014 041 PDF2 pages
- KR 1000 Titan: Our Powerful Robot Für Heavy LoadsNo ratings yetKR 1000 Titan: Our Powerful Robot Für Heavy Loads3 pages
- Amca Publication 1011-03: Certified Ratings Program - Product Rating Manual For Acoustical Duct SilencersNo ratings yetAmca Publication 1011-03: Certified Ratings Program - Product Rating Manual For Acoustical Duct Silencers18 pages
- R3-1 (QTY: 14) : 60 KPH Speed Limit SignNo ratings yetR3-1 (QTY: 14) : 60 KPH Speed Limit Sign22 pages
- Strategic Maintenance Management 101 PDFNo ratings yetStrategic Maintenance Management 101 PDF76 pages
- Lee, Kang, Shin - 2012 - Advanced Taper Tension Method For The Performance Improvement of A Roll-To-Roll Printing Production Line With ANo ratings yetLee, Kang, Shin - 2012 - Advanced Taper Tension Method For The Performance Improvement of A Roll-To-Roll Printing Production Line With A12 pages
- Placement Summary For The Batch - 2018-19: VNR Vignana Jyothi Institute of Engineering & TechnologyNo ratings yetPlacement Summary For The Batch - 2018-19: VNR Vignana Jyothi Institute of Engineering & Technology1 page
- Special Consideration While Aligning Hill RoadNo ratings yetSpecial Consideration While Aligning Hill Road16 pages
