@slavapestov probably has the context to know what's going wrong.

This doesn't work in Swift 4.2 either:

lazy.swift:14:9: error: value of type 'Foo' has no member 'a'
                print(a)
                      ^
lazy.swift:8:11: note: did you mean 'a'?
        lazy var a = run(Fixture()) { _ in
                 ^

Is the example complete? I don't see any way we could infer the type of the result of 'a' or 'b' here.

My reduced example was faulty. I've made a better test case.

The following code compiles with Swift 4.1, but not Swift 5 or Swift 4.2.1:

@discardableResult
func with<T>(_ value: T, update: (inout T) throws -> Void) rethrows -> T {
    var copy = value
    try update(&copy)
    return copy
}

final class Fixture {
    var onAction: (() -> Void)?
}

final class Fixture2 {}

final class Foo {
    lazy var a = with(Fixture()) {
        print("")

        $0.onAction = {
            print(self.b)
        }
    }

    lazy var b = with(Fixture2()) { _ in
        print(self.a)
    }
}

I've confirmed it compiles by using the Swift 4.1 version here: https://www.jdoodle.com/execute-swift-online

Ah, I see. One of the closures is a multiple-statement closure.

The difference is subtle. In 4.1, we would first compute the type of the property without applying the solution. This would tell us the type of the lazy property. Then we would type check it again, and this time apply a solution, which type checks multiple-statement closure bodies. At this point, it is safe to refer to self.a or self.b, which now have types.

In 4.2, we type check the initializer expression in one shot, including multiple-statement closures, before we assign an inferred type to the property. So the circular reference is rejected because at the time we see the 'self.a' reference inside 'self.b', we still haven't assigned a type to 'self.a' yet.

@rjmccall You worked on this stuff most recently – do you have any suggestions? I wonder if we can delay type checking multiple-statement closure bodies in general to resolve cycles such as this.

@sindresorhus Going back to the 4.1 behavior is non-trivial and I can't promise when or if it will happen at this point. However, as a workaround, you can explicitly declare the type of the lazy property in case of circularity like this.

I'm fine with this having become ill-formed without a type annotation, but if we feel compelled to make it work, I guess delaying closure bodies in some cases is probably acceptable.