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
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.