[5.8] In Swift 5.8, if a property of a optional value is assigned within a closure, it will cause the type inference of the closure's return value to change from void to optional void.

[CrazyFanFan]

In Swift 5.8, if a property of a optional value is assigned within a closure, it will cause the type inference of the closure's return value to change from void to optional void.

Description

Run the following code

class Foo {
    var value: Int = 1
}

var inner: Foo?
func foo() {
    let action = {
        inner?.value = 1
    }

    print(type(of: action))
}

foo()

Output

() -> Optional<()>

Environment

• Xcode: Version 14.3 beta 2 (14E5207e)
• Swift

swift-driver version: 1.75.1 Apple Swift version 5.8 (swiftlang-5.8.0.119.11 clang-1403.0.22.11.100)
Target: arm64-apple-macosx13.0

[JessyCatterwaul]

This is not specific to closures or 5.8, or a bug.

var value: Optional = 1
type(of: value? = 1) // Void?.self

[AnthonyLatsis]

How is value? = 1 legal in the first place?

Edit: Haha I never knew Swift had built-in optional assignments

cc @xedin

[xedin]

Optional projects l-valueness of it's object out that's how ? chains work.

[AnthonyLatsis]

Optional projects l-valueness of it's object out that's how ? chains work.

I understand, somehow I just never realized (or forgot) that the postfix ? restriction was limited to loads, and not writes as well.

---

Back to the issue. This has been the case since around Swift 5.0 for the original example due the implicit return statement (i.e., since the feature was introduced), and even older versions if we’re talking about explicit returns. It has to do with the way we model these expressions in the AST. On one hand, the optionality comes with a bonus:

let didAssign = (w?.x?.y = z) != nil

But I agree that { inner?.value = 1 } is generally expected to be () -> Void.