Some reviewers expressed concern about a perceived shift in the meaning of let that allows the "mutation" of the weak reference becoming nil. The Language Steering Group is satisfied with the explanation in the proposal that the weak reference itself remains constant, and it's simply that the act of observing it will begin to yield nil after the referent is destroyed. The fact (as pointed out in the review) that weak vars do not trigger the observing willSet / didSet accessors when they become nil is also consistent with this way of understanding weak references. The LSG further notes that the mutability story of let in complex cases was recently complicated by the introduction of atomic values and mutexes, which must be declared with let, although we believe weak let can be more simply understood.
There was some discussion in the review about let property wrappers and computed let properties. The LSG does not see any reason to hold up or complicate this feature, where the interpretation of let is natural and immediately useful, over potential changes to other features. Community members interested in these ideas should pitch them separately.
Accordingly, SE-0481 is accepted.
As always, I'd like to thank the reviewers for their contributions; participating in open review is a key part of making Swift a better language.
I don't really see the connection to SE-0481, but I'll try to answer it. A lazy var instance property of an actor cannot be safely nonisolated both because the lazy-initialization sequence is not thread-safe and because it is a mutable variable. lazy let would address the latter but not the former. The lazy-initialization sequence could theoretically be made thread-safe (as long as the initializer does not require isolation), the same way we do with globals, but it would require a significant per-property storage overhead in the actor. It might also need new runtime support.
That makes total sense. I thought maybe we were chipping away at the formal definition of let to an extent that lazy let might begin to make sense… but that's on me for not reading the proposal close enough. There was no explicit discussion of lazy let so I understand that should not be part of the same discussion.
I directly addressed that in the announcement post (and the same applies to lazy let). The LSG is perfectly happy to see proposals that are narrowly focused on fixing specific problems.
It was stated that the following code would throw the compilation error: error: reference to captured var 'c' in concurrently-executing code
However for me it compiles without any error
final class C: Sendable {
func foo() {}
}
func makeClosure() -> @Sendable () -> Void {
let c = C()
return { [weak c] in
c?.foo() // expected compilation error but no compilation error
c = nil // allowed, but surprising and very rare
}
}
