Is it safe to force unwrap variables that have bee

Question

someFunction(completion: { [weak self] in
    self?.variable = self!.otherVariable
})

Is this always safe? I access the optional self in the beginning of the statement, and personally I assume that the second part of this statement will never be executed if self is nil. Is this true? If self indeed is nil, the second part will never happen? And it will never happen that self could be 'nilled' during this single line of code?

Answer 1

The documentation clearly states that, if the left side of the assignment is determined to be nil, right side will not be evaluated. However, in the given example self is weak reference and may be released (and nullified) right after the optional check passes, but just before force-unwrap will happen, making the whole expression nil-unsafe.

Answer 2

Optional Chaining from "The Swift Programming Language" gives the following example:

 let john = Person()
 // ...
 let someAddress = Address()
 // ...
 john.residence?.address = someAddress

followed by (emphasis added):

In this example, the attempt to set the address property of john.residence will fail, because john.residence is currently nil.

The assignment is part of the optional chaining, which means none of the code on the right hand side of the = operator is evaluated.

Applied to your case: In

self?.variable = self!.otherVariable

the right-hand side is not evaluated if self is nil. Therefore the answer to your question

If self indeed is nil, the second part will never happen?

is "yes". With regard to the second question

And it will never happen that self could be 'nilled' during this single line of code?

My original assumption was that once self has been determined to be != nil, a strong reference to self! is held throughout the evaluation of the statement, so that this can not happen. However (as @Hamish pointed out), this is not guaranteed. Apple engineer Joe Groff writes at Confirming order of operations in the Swift forum:

This isn't guaranteed. Releases may be optimized to happen earlier than this, to any point after the last formal use of the strong reference. Since the strong reference loaded in order to evaluate the left-hand side weakProperty?.variable is not used afterward, there is nothing keeping it alive, so it could be immediately released.
If there are any side effects in the getter for variable that cause the object referenced by weakProperty to be deallocated, nil-ing out the weak reference, then that would cause the force-unwrap on the right side to fail. You should use if let to test the weak reference, and reference the strong reference bound by the if let

Answer 3

Is this always safe

No. You are not doing the "weak-strong dance". Do it! Whenever you use weak self, you should unwrap the Optional safely, and then refer only to the result of that unwrapping — like this:

someFunction(completion: { [weak self] in
    if let sself = self { // safe unwrap
        // now refer only to `sself` here
        sself.variable = sself.otherVariable
        // ... and so on ...
    }
})

Answer 4

No, this is not safe

As pointed out by @Hamish in a comment below, Swift Compiler Engineer Joe Groff describes that there is no guarantee that a strong reference is held for the duration of the RHS' evaluation [emphasis mine]

Confirming order of operations

Rod_Brown:

Hi there,

I’m wondering about the safety of a type of access on a weak variable:

class MyClass {

    weak var weakProperty: MyWeakObject?

    func perform() {
        // Case 1
        weakProperty?.variable = weakProperty!.otherVariable

        // Case 2
        weakProperty?.performMethod(weakProperty!)
    }
}

With the two cases above, is it guaranteed by Swift that the weakProperty can be force unwrapped at these positions?

I’m curious about the guarantees Swift makes about access during optional chaining E.g. are the weakProperty! accessors guaranteed to only fire iff the optional chaining determines first that the value is already non-nil?

Additionally, is the weak object guaranteed to be retained for the duration of this evaluation, or can the weak variable potentially be able to deallocate between the optional access and the method being called?

Joe_Groff:

This isn't guaranteed. Releases may be optimized to happen earlier than this, to any point after the last formal use of the strong reference. Since the strong reference loaded in order to evaluate the left-hand side weakProperty?.variable is not used afterward, there is nothing keeping it alive, so it could be immediately released. If there are any side effects in the getter for variable that cause the object referenced by weakProperty to be deallocated, nil-ing out the weak reference, then that would cause the force-unwrap on the right side to fail. You should use if let to test the weak reference, and reference the strong reference bound by the if let:

if let property = weakProperty {
  property.variable = property.otherVariable
  property.performMethod(property)
}

This should safer and also more efficient, since the weak reference is loaded and tested once instead of four times.

---

Given the answer quoted answer by Joe Groff above, my previous answer is moot, but I will leave it here as a possibly interesting (albeit failed) journey into the depths of the Swift compiler.

---

Historical answer reaching an in-correct final argument, but through an interesting journey, nonetheless

I'll base this answer upon my comment to @appzYourLife:s deleted answer:

This is pure speculation, but considering the somewhat close connection between many of the experienced Swift core devs and C++:s Boost lib, I would assume that weak reference is locked into a strong one for the lifetime of the expression, if this assigns/mutates something in self, much like the explicitly used std::weak_ptr::lock() of the C++ counterpart.

Let's have a look at your example, where self has been captured by a weak reference and is not nil when accessing the left hand side of the assignment expression

self?.variable = self!.otherVariable
/* ^             ^^^^^-- what about this then?
   |
    \-- we'll assume this is a success */

We may look at the underlying treatment of weak (Swift) references in the Swift runtime, swift/include/swift/Runtime/HeapObject.h specifically:

/// Load a value from a weak reference.  If the current value is a
/// non-null object that has begun deallocation, returns null;
/// otherwise, retains the object before returning.
///
/// \param ref - never null
/// \return can be null
SWIFT_RUNTIME_EXPORT
HeapObject *swift_weakLoadStrong(WeakReference *ref);

The key here is the comment

If the current value is a non-null object that has begun deallocation, returns null; otherwise, retains the object before returning.

Since this is based on backend runtime code comment, it is still somewhat speculative, but I would say that the above implies that when attempting to access the value pointed to by a weak reference, there reference will indeed be retained as a strong one for lifetime of the call ("... until returning").

---

To try to redeem the "somewhat speculative" part from above, we may continue to dig into how Swift handles access of a value via a weak reference. From @idmean:s comment below (studying the generated SIL code for an example like the OP:s) we know that the swift_weakLoadStrong(...) function is called.

So we'll start by looking into the implementation of the swift_weakLoadStrong(...) function in swift/stdlib/public/runtime/HeapObject.cpp and see where we'll get from there:

HeapObject *swift::swift_weakLoadStrong(WeakReference *ref) {
  return ref->nativeLoadStrong();
}

We find the implementation of the nativeLoadStrong() method of WeakReference from swift/include/swift/Runtime/HeapObject.h

HeapObject *nativeLoadStrong() {
  auto bits = nativeValue.load(std::memory_order_relaxed);
  return nativeLoadStrongFromBits(bits);
}

From the same file, the implementation of nativeLoadStrongFromBits(...):

HeapObject *nativeLoadStrongFromBits(WeakReferenceBits bits) {
  auto side = bits.getNativeOrNull();
  return side ? side->tryRetain() : nullptr;
}

Continuing along the call chain, tryRetain() is a method of HeapObjectSideTableEntry (which is essential for the object lifecycle state machine), and we find its implementation in swift/stdlib/public/SwiftShims/RefCount.h

HeapObject* tryRetain() {
  if (refCounts.tryIncrement())
    return object.load(std::memory_order_relaxed);
  else
    return nullptr;
}

The implementation of the tryIncrement() method of the RefCounts type (here invoked via an instance of a typedef:ed specialization of it) can be found in the same file as above:

// Increment the reference count, unless the object is deiniting.
bool tryIncrement() {
  ...
}

I believe the comment here suffices for us to use this method as an end point: if the object is not deiniting (which we've assumed above that it does not, as the lhs of assignment in the OP:s example is assumed to be successful), the (strong) reference count on the object will be increased, and a HeapObject pointer (backed by a strong reference count increment) will be passed to the assignment operator. We needn't study how the corresponding reference count decrement is eventually performed at the end of the assignment, but now know beyond speculation that the object associated with the weak reference will be retained as a strong one for the lifetime of the assignment, given that it has not been freed/deallocated at the time of the left hand side access of it (in which case the right hand side of it will never be processed, as has been explained in @MartinR:s answer).

Answer 5

BEFORE CORRECTION:

I think others have answered the details of your question far better that I could.

But aside from learning. If you actually want your code to reliably work then its best to do as such:

someFunction(completion: { [weak self] in
    guard let _ = self else{
        print("self was nil. End of discussion")
        return
    }
    print("we now have safely 'captured' a self, no need to worry about this issue")
    self?.variable = self!.otherVariable
    self!.someOthervariable = self!.otherVariable
}

AFTER CORRECTION.

Thanks to MartinR's explanation below I learnt a great deal.

Reading from this great post on closure capturing. I slavishly thought whenever you see something in brackets [] it means it's captured and its value doesn't change. But the only thing we're doing in the brackets is that we are weak-ifying it and making it known to ourselves that it's value could become nil. Had we done something like [x = self] we would have successfully captured it but then still we'd have the problem of holding a strong pointer to self itself and be creating a memory cycle. (It's interesting in the sense it's a very thin line from going to creating a memory cycle to creating a crash due to the value being deallocated because you weak-ified it).

So to conclude:

1. [capturedSelf = self]

   creates memory cycle. Not good!

2. [weak self] 
   in guard let _ = self else{
   return
   } 
   

   (can lead to crash if you force self unwrap afterwards) the guard let is it utterly useless. Because the very next line, still self can become nil. Not good!

3. [weak self] 
   self?.method1()
   

   (can lead to crash if you force self unwrap afterwards. Would go through if self is non-nil. Would fail safely if self is nil.) This is what most likely what you want. This is Good!

4. [weak self] in 
   guard let strongSelf = self else{ 
   return
   } 
   

   Will fail safely if self was deallocated or proceed if not nil. But it kinda defeats the purpose, because you shouldn't need to communicate with self when it removed it's own reference. I can't think of a good use case for this. This is likely useless!