[swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization
Joe Groff
jgroff at apple.com
Thu Jan 7 20:55:47 CST 2016
The proposal says that "let" properties with inline initializers should be left out of the memberwise initialization, AIUI on the grounds that a manually-written initializer would not be allowed to override the inline initialization:
class C {
let x = 1738
init(x: Int = 679) {
self.x = x // Error, self.x already initialized
}
}
However, this is also true for vars. Semantically, if you change 'x' to a var in the above example, you get an initialization followed by an assignment:
class C {
let x = dump(1738)
init(x: Int = dump(679)) {
self.x = x
}
}
C() // dumps 1738, then 679
which, if the initialization has side effects, will likely be surprising. We could say that the memberwise initializer elides the inline initialization of `var`s, on the grounds that initializations ought not to have side effects, but then we're introducing a behavior change in inline initializers for `var`s in the face of `memberwise` initializers that also cannot be replicated by a manually-written initializer. If we make that behavior change for vars, I think it's reasonable, and more orthogonal, to extend the same grace to lets as well. That also simplifies the rules for what appears in the memberwise initializer—there's now only two rules (or one, if we also remove the access control filter, as I've suggested in another subthread).
-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/5f0832a1/attachment.html>
More information about the swift-evolution
mailing list