Swift Proposal: Init Accessors
Swift applies definite initialization analysis to stored properties, stored local variables, and variables with property wrappers. Definite initialization ensures that memory is initialized on all paths before it is accessed. A common pattern in Swift code is to use one property as backing storage for one or more computed properties, and abstractions like property wrappers and attached macros help facilitate this pattern. Under this pattern, the backing storage is an implementation detail, and most code works with the computed property, including initializers.
[…]
The ad-hoc nature of property wrapper initializers mixed with an exact definite initialization pattern prevent property wrappers with additional arguments from being initialized out-of-line. Furthermore, property-wrapper-like macros cannot achieve the same initializer usability, because any backing storage variables added must be initialized directly instead of supporting initialization through computed properties. For example, the
@Observablemacro applies a property-wrapper-like transform that turns stored properties into computed properties backed by the observation APIs, but it provides no way to write an initializer using the original property names like the programmer expects[…][…]
This proposal adds
initaccessors to opt computed properties on types into definite initialization that subsumes initialization of a set of zero or more specified stored properties, which allows assigning to computed properties in the body of a type’s initializer[…]
Previously:
- Using Lazy Variables to Work Around Swift Initialization Rules
- Strange Tales of Swift Initialization
2 Comments RSS · Twitter · Mastodon
are all these language feature’s supposed to make my life as an app developer better?
Honestly, stuff like this just makes my eyes glaze over and my brain shut down.