Is it normal that lazy var property is initialized twice?

Question

I have met quite weird case once I used a property with lazy keyword. I know this keyword indicates that an initialization of the property will be deferred until th

Answer 1

The entire conception of your code is wrong.

• In prepareForSegue, you must not refer to the interface of the destination view controller, because it has no interface. viewDidLoad has not run yet; the view controller has no view, no outlets, no nothing.

• Your lazy initializer for the label property should not also add the label to the interface. It should just make the label and return it.

Other things to know:

• Referring to a view controller's view before it has a view will force that view to load prematurely. Doing this wrong can actually cause the view to load twice, which can have terrible consequences.

• The only way to ask a view controller whether its view has loaded yet, without forcing the view to load prematurely, is with isViewLoaded().

The correct procedure for what you want to do is:

• In prepareForSegue, assign the name string to a name property and that's all. It can have an observer, but that observer must not refer to view if we have no view at the time, because doing so will cause the view to load prematurely.

• In viewDidLoad, then and only then do we have a view, and now you may begin populating the interface. viewDidLoad should create the label, put it into the interface, then pick up the name property, and assign it to the label.

---

EDIT:

Now, having said all that... What does it have to do with your original question? How does what you are doing wrong here explain what Swift is doing, and is what Swift is doing itself wrong?

To see the answer, simply put a breakpoint on:

lazy var testLabel: UILabel = {
    NSLog("testLabel self = \(self)") // breakpoint here
    // ...

What you'll see is that, because of the way you structured your code, we are getting the value of testLabel twice recursively. Here's the call stack, slightly simplified:

prepareForSegue
name.didset
testLabel.getter -> *
viewDidLoad
testLabel.getter -> *

The testLabel getter refers to the view controller's view, which causes the view controller's view to be loaded, and so its viewDidLoad is called and causes the testLabel getter to be called again.

Note that the getter is not merely being called twice in sequence. It is being called twice recursively: it itself is, in effect, calling itself.

It is this recursion that Swift is failing to defend against. If the setter were merely called twice in succession, the lazy initializer would not have been called the second time. But in your case, it is recursive. So it is true that the second time, the lazy initializer has never been run before. It has been started, but it has never been completed. Thus, Swift is justified in running it now - which happens to mean running it again.

So, in a sense, yes, you've caught Swift with its pants down, but what you had to do in order to make that happen is so outrageous that it can be justifiably called your own fault. It might be Swift's bug, but if so, it is a bug that should simply never be encountered in real life.

---

EDIT:

In the WWDC 2016 video on Swift and concurrency, Apple is explicit about this. In Swift 1 and 2, and even in Swift 3, lazy instance variables are not atomic, and thus the initializer can run twice if called from two contexts simultaneously — which is exactly what your code does.