Guard condition provokes compiler error that talks about closure

Question

Consider this code:

class Foo {
    var a: Int
    var b: Int

    init(a: Int, b: String?) throws {
        self.a = a

        guard self.a > 0 else {
            throw "Too little a!"
        }
        self.b = self.a
    }
}

extension String: Error {}

Pretty non-sensical, but the point is that it compiles fine. Now replace the guard with:

guard b == nil || self.a > 0 else {

Not we get a compiler error!

Error: 'self' captured by a closure before all members were initialized

I for one don't see a closure anywhere. Is the compiler translating guard conditions into closures if they are compound expressions, thus introducing the error (which would be correct if there was a closure)?

Bug or feature?

This is with Swift 3.0.2.

The compiler is technically correct though. You should be checking 'a' not 'self.a'. The closure is probably @autoclosure. — Sulthan, Mar 28 '17 at 16:03
The `||` operator is implemented with an `@autoclosure` second parameter to allow for short-circuiting, compare http://stackoverflow.com/q/28648268/2976878 — Hamish, Mar 28 '17 at 16:25
@Sulthan Obviously, this is an artifical MWE, yes. The actual computation of `self.a` may be complex, the assignment itself happening in nested `if`s, etc. — Raphael, Mar 28 '17 at 16:30
@Hamish Huh, so turning around the two even gets rid of the error here; but that's of course not an option if lhs is the nil check that rhs repends on\. D'oh. This ... kind of sucks. The principle of least surprise doesn't even remember it existed... — Raphael, Mar 28 '17 at 16:31
@Raphael Yeah, I agree it's not ideal – realistically there's no harm (that I'm aware of) in capturing `self.a` after `self.a` has been initialised. But there are a number of workarounds you can do, such as creating a local variable with the value of `self.a` (obviously assuming `a` != `self.a`). See also [this related Q&A](http://stackoverflow.com/q/38291580/2976878). — Hamish, Mar 28 '17 at 16:41
The "weird" signaturs of `||` and similar prevents them from being passed to methods like `reduce` as expected: `[true, false].reduce(true, &&)` does not compile. (cc @Hamish) — Raphael, May 17 '17 at 12:55
@Raphael Yup, compare [Use logical operator as combine closure in reduce](http://stackoverflow.com/q/34699576/2976878) & the related bug report [SR-1793](https://bugs.swift.org/browse/SR-1793). Using `contains(_:)` as shown in the linked Q&A is probably the best solution in that specific case as it allows for short-circuiting, whereas `reduce(_:_:)` would evaluate the entire sequence. Although it is a shame the compiler doesn't currently permit the conversion from a function with auto-closure parameter(s) to a function with non auto-closure parameter(s)... — Hamish, May 17 '17 at 13:13
... as also shown in the linked Q&A, you can always define your own closure expression in order to act as a thunk between the two. — Hamish, May 17 '17 at 13:15

score 2 · Accepted Answer · edited May 23 '17 at 12:03

The problem, as explained by Martin in this Q&A, is that the || operator is implemented with an @autoclosure second parameter, in order to allow for short-circuit evaluation (the right hand expression need only be evaluated if the left hand expression evaluates to false).

Therefore in the expression

b == nil || self.a > 0

self.a > 0 is implicitly wrapped in a () -> Bool closure. This is problematic, because it requires the capture of self, so that a can be accessed upon applying the closure.

However, in an initialiser, Swift tightly restricts what you can do with self before it has been fully initialised. One of these restrictions is the inability to be captured by a closure – which is why you get a compiler error.

Although really, there's nothing wrong with the closure { self.a > 0 } capturing self before it's fully initialised, because all the closure is doing is accessing a on it, which has already been initialised. Therefore, this is really just an edge case (for which there's an open bug report), which I hope will be smoothed out in a future version of the language.

Until then, one solution as shown by Martin in this Q&A, is to use a temporary local variable to create a copy of the value of self.a, avoiding the capturing of self in the closure:

class Foo {
    var a: Int
    var b: Int

    init(a: Int, b: String?) throws {

        // some computation meaning that a != self.a
        self.a = a * 42

        // temporary local variable to be captured by the @autoclosure.
        let _a = self.a
        guard b == nil || _a > 0 else {
            throw "Too little a!"
        }

        self.b = self.a
    }
}

extension String: Error {}

Obviously, this assumes that self.a != a, otherwise you can just refer to a instead of self.a in the guard condition.

In my case, rhs can't be evaluated if lhs is true, so the "preparation" of the condition is more complicated; I end up with nested conditions, defeating the value `guard` brings. :/ Thanks for the elaborate explanation and the links! — Raphael, Mar 29 '17 at 06:48

Guard condition provokes compiler error that talks about closure

1 Answers1