The review of SE-0400: Init Accessors ran from June 14th through July 10th. The language steering group has decided to accept the proposal, including the two revisions that the authors made before the review was extended:
- Rather than the initialized and accessed properties being specified as part of the effects clause, they are now specified as part of the (new)
@storageRestrictions(initializes:accesses:)attribute attached to the
- The body of the memberwise init will be synthesized such that properties are initialized in the order necessary to satisfy the
accesseslists of any
Much of the proposal feedback struck a note of being somewhat ambivalent about the feature in a vacuum, but supportive of the broad goal of moving in a direction where macros could subsume property wrappers. The language steering group agrees that this goal is a good one.
Several participants requested the extension of this feature to all type members, to, e.g., allow a specific function to be called into by the type's initializers in order to do common initialization of a fixed set of properties. The language steering group felt that this was not an unreasonable future direction, but that it did not need to be included as part of this proposal in order to make the feature useful.
Other feedback was largely bikeshedding about how to spell the designation of the initialized and accessed properties. The language steering group agreed that it was desirable to have a single attribute to specify both sets of properties, and that moving it out of the effects clause of the
init accessor also made sense. While we were sympathetic to the point that the specific name of
@storageRestrictions is somewhat verbose, the language steering group believes that:
- "Restrictions" is a reasonable description of what the specified sets of properties do, since those in the
initializes:clause impose a restriction on which stored properties must be initialized by the end of the accessor, and those in the
accesses:clause restrict which properties must already be initialized before the accessor is called.
- None of the suggestions from the review thread, nor any alternatives we could think of based on the review feedback, felt like obvious improvements.
- A major use case for this feature is macros, wherein the verbosity of the spelling is nearly a non-issue since end users will not be writing it in code.
- Beyond macros, it will be a narrowly used feature that would benefit from a clear, unambiguous name more than it would terseness.
Thank you to everyone who participated in this review!