The review of SE-0258: Property Wrappers (previously called "Property Delegates") begins now and runs through July 3rd, 2019. This is the third review of SE-0258. After the first review, the Core Team requested further development of the proposal to address some concerns raised during the review. That development led to a major revision and a second review. After considering the early feedback during the second review, the proposal authors asked to make a second round of revisions, and the Core Team has decided that those changes are substantial enough to require a third review.
Doug Gregor has provided the following list of differences from the previous revision:
-
The synthesized property storage is always named with a leading
_
and is alwaysprivate
; hence@Wrapper var foo
synthesizes the storageprivate var _foo: Wrapper
. -
The
wrapperValue
property has been renamed toprojectedValue
to more clearly distinguish it visually fromwrappedValue
. This also gives us the term "projection" or "projected property" for talking about the$
property. -
The projected property (e.g.,
$foo
) always has the same access as the original wrapped property, rather than being artificially limited tointernal
. This reflects the idea that, for those property wrapper types that provide a projection, the projection is equal in importance to the wrapped value in the API of the property.
The rest of SE-0258 remains unchanged. Accordingly, the Core Team felt that it was reasonable to consider the feedback it received during the second review, at least as far as that feedback didn't relate to the aspects being further revised. We continue to believe that this is a highly worthy proposal, and we feel that the first round of revisions addressed most of the concerns we raised before. After the first review, we declared our acceptance of certain aspects of the proposal in the interest of forestalling further debate on points that we considered well-enough settled. We'd now like to augment that:
-
The Core Team accepts the proposed approach to wrapper composition and feels that any further refinements can reasonably be left as possible future work.
-
The Core Team accepts the spelling
$property
for a wrapper's primary projection. -
The Core Team does not currently see sufficient justification for secondary projections (e.g.
property$view
) and is persuaded that this can be left as possible future work. -
The Core Team is satisfied with the name "property wrapper" even though this may be inapposite for other kinds of variable in the future. The term
property
is not overly intrusive in the source, the alternatives seem over-technical and sometimes misleading, and properties are undeniably the most important subject for this pattern.
We would like to encourage reviewers to focus on the latest revisions and how they change your view of the proposal.
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.
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.
John McCall
Review Manager