init accessors.
#2042
init accessors.
#2042
Conversation
* Expand description of accesses and give a "dictionary storage" example * Make the name of the `newValue` parameter configurable Be consistent with set/willSet/didSet in making the parameter name optional and overridable. * A few clarifications regarding init accessor signatures * Clarify the rules for definite initialization Expand the examples and show the case where virtual and stored-property initialization collide. --------- Co-authored-by: Holly Borla <[email protected]>
proposals/NNNN-init-accessors.md
Outdated
| self.point = (x, y) // error: neither the `init` accessor nor the setter can be called here | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
A case that I don't think is covered here: what about a computed property with an init accessor which is conditionally initialized along some path, and then reassigned?
struct S {
var x: Int {
init initializes(y) {
y = newValue
}
get { ... }
set { ... }
}
var y: Int
init(x: Int, y: Int) {
if y > 0 {
self.x = 0
}
self.x = x
}
}
There was a problem hiding this comment.
An assignment to a property that is not initialized on all paths will call the init accessor again. This is a generalization of what property wrappers do. I can add this example to the proposal.
proposals/NNNN-init-accessors.md
Outdated
|
|
||
| ### Memberwise initializers | ||
|
|
||
| If a struct does not declare its own initializers, it receives an implicit memberwise initializer based on the stored properties of the struct, because the storage is what needs to be initialized. Because `init` provide a preferred mechanism for initializing storage, the memberwise initializer parameter list will include any computed properties that subsume the initialization of stored properties instead of parameters for those stored properties. |
There was a problem hiding this comment.
Because
initprovide a preferred mechanism for initializing storage, the memberwise initializer parameter list will include any computed properties that subsume the initialization of stored properties instead of parameters for those stored properties.
I think this is a perfectly reasonable position, but I wonder if the notion that init accessors represent the preferred initialization strategy deserves mention as part of Proposed solution rather than just being a side mention in a subsection of Detailed design. That's a not-insignificant policy decision about the feature!
There was a problem hiding this comment.
Concretely, I think the "preferred mechanism" thing (and its relationship to the memberwise init) is the only thing in this proposal that casts doubt on what otherwise seems a perfectly reasonable use of init accessors: having multiple computed properties which initialize the same underlying storage, e.g., radians and rotations both initializing degrees.
There was a problem hiding this comment.
I added more commentary in the Proposed Solution and in this section about member-wise initializers.
Co-authored-by: Frederick Kellison-Linn <[email protected]>
hborla
force-pushed
the
init-accessors
branch
2 times, most recently
from
6fe4a46 to
5ccb0bb
Compare
|
@Jumhyn I believe I've addressed all of your feedback, and I strengthened the Alternatives Considered section with some suggestions from the pitch thread. Please let me know if you have any further feedback! |
Pitched here: https://forums.swift.org/t/pitch-init-accessors/64881