Comment by Paul Eipper (JIRA)

I would expect this to be the case since it's true also for other methods called from init or a closure:

struct Foo {
    var x: Int {
        didSet {
            print("Foo.x.didSet: \(oldValue) -> \(x)")
        }
    }
    init() {
        x = 1
        // closure invokes didSet
        ({ x = 2 })()
    }
}
_ = Foo()

And:

struct Foo {
    var x: Int {
        didSet {
            print("Foo.x.didSet: \(oldValue) -> \(x)")
        }
    }
    init() {
        x = 1
        // mutating method invokes didSet
        setX(2)
    }

    mutating func setX(newX: Int) {
        x = newX
    }
}
_ = Foo()

But a defer block isn't a method. The fact that it seems to be treated basically like a block under the hood is entirely an implementation detail, and the fact that you can observe this detail should be considered a bug.

Comment by Paul Eipper (JIRA)

From the docs:

A defer statement defers execution until the current scope is exited.

It is pretty clear a defer is executed after the current scope is exited, in this case, after init has finished.

That's the complete opposite of how I read it. What that quoted bit means to me is a defer statement is executed at the time the current scope is executed. It does mean it's executed after the scope is exited. I'm not sure how you consider that a valid interpretation at all, because how can a function execute code after the function has returned? Clearly the execution is happening prior to the function actually returning control to its caller.

To back up my interpretation, here's a bit of sample code:

final class DeallocSpy {
    deinit {
        print("deinit")
    }
}

func foo() {
    let foo = DeallocSpy()
    defer {
        print("defer block")
    }
}

foo()

Under your interpretation, the output would have to be

deinit
defer block

But in fact the output is

defer block
deinit

This proves that the defer block is being executed before previously-declared local variables are cleaned up.

Comment by Paul Eipper (JIRA)

Getting back to why observers are not called on initialization, it's because they might depend on other properties that might not be set yet.

Executing from defer makes sure all initialization is done, so the observers don't have the dependency issue anymore and are cleared to trigger.

Code executed in the 2nd step of 2-phase initialization also guarantees that all properties are set, and yet property observers are still not fired. This leads to a very simple rule: Modifying properties (that were declared on the current class) from within an initializer doesn't fire observers. And I see no reason why defer blocks should behave any differently. As far as the user is concerned, a defer block is identical to copying & pasting the contents immediately prior to every return. The actual fact of how it's implemented is just an implementation detail and should not be exposed to the user. The fact that it is exposed is a bug.

Comment by Paul Eipper (JIRA)

PS: regarding the code sample, yes, it will run while the stack is still available to allow access to variables, but it will run after the defining scope has finished all execution.