The review of SE-0258: Property Wrappers (previously called "Property Delegates") begins now and runs through June 24th, 2019. This is the second review of SE-0258, which was returned for revision subsequent to its first review.
Doug Gregor has provided the following list of differences from the previous revision:
- The name of the feature has been changed from "property delegates" to "property wrappers" to better communicate how they work and avoid the existing uses of the term "delegate" in the Apple developer community
- When a property wrapper type has a no-parameter
init(), properties that use that wrapper type will be implicitly initialized via
- Support for property wrapper composition has been added, using a "nesting" model.
- A property with a wrapper can no longer have an explicit get or set declared, to match with the behavior of existing, similar features (
- A property with a wrapper does not need to be
- Reduced the visibility of the synthesized storage property to
- When a wrapper type provides
wrapperValue, the (computed)
internal(at most) and the backing storage variable gets the prefix
- Removed the restriction banning property wrappers from having names that match the regular expression
Equatablesynthesis are now based on the backing storage properties, which is a simpler model that gives more control to the authors of property wrapper types.
- Improved type inference for property wrapper types and clarified that the type of the
wrappedValueproperty is used as part of this inference. See the "Type inference" section.
- Renamed the
wrappedValueto avoid conflicts.
- Initial values and explicitly-specified initializer arguments can both be used together; see the
Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via email or direct message on the forums. If you send me email, please put "SE-0258" somewhere in the subject line.
Notice as of June 19th: further revisions to this proposal are expected; the review period will be extended when the revised proposal is ready
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Thank you for contributing to Swift.