The review for SE-0258 has concluded. There was a lot of great discussion in this review, leading to some very useful feedback for the Core Team and the proposal authors. That feedback can be broken down into two categories: (1) procedural feedback about the state of the proposal and its review and (2) technical feedback about the actual proposal. Both are useful, and we'll consider each in turn.
Several members of the community felt that this proposal just wasn't ready for review, and the Core Team agrees with these concerns. Some aspects of the proposal seem a little under-justified, while others seem awkwardly designed. Both of these points suggest that further development is required, whether to improve the rationales in the proposal text or to substantively improve the design. Accordingly, the Core Team has decided to return the proposal for further design and development. Crucially, this result differs from rejection in that the Core Team accepts that this is a worthwhile feature in general and would be pleased to accept a version of this proposal that satisfies the concerns covered in this announcement. The Core Team feels that this result is consistent with the general tenor of the feedback received.
The Core Team wishes to establish a productive framework for further discussion, and so we are providing the following guidance about specific technical aspects of the proposal:
The Core Team accepts the general custom-attribute design laid out in this proposal as a useful way of generalizing existing modifiers (whether keyword- or attribute-based) and creating a namespace for future extensions.
The Core Team accepts the specific use of custom attributes in this proposal for specifying the delegate type. We are not concerned that this will exhaust the attribute namespace or "claim" it for just this one feature. We are also convinced, after some preliminary investigation, that choosing an attribute-based spelling will not preclude composition of delegates in the future.
The Core Team agrees with the proposal that composition of delegates is not necessary to solve in the initial design.
The Core Team accepts the proposal's use of an attribute and ad hoc requirements to define a delegate type rather than using a formal protocol. A formal protocol would substantially limit the expressivity of the feature.
The Core Team feels that the proposal fails to justify
delegateValuewell enough for it to be evaluated. This feature was developed late in the pitch phase and added to the proposal without much discussion, and it adds a substantial amount of conceptual complexity. The proposal should explain the purpose of this feature well enough that the community (and Core Team) can meaningfully evaluate the proposed approach and consider alternatives to it.
The Core Team feels that the ability to explicitly specify getters and setters is similarly inadequately justified.
The Core Team agrees with the community that the inability to control access to the delegate storage is a serious concern. It's okay in principle for a proposal to just pick a reasonable default rule like this for certain language interactions, but we do need some assurance that we're not going to be stuck with bad compromises in the future. For something like access control, establishing that there's room for an acceptable design basically means doing most of the work, so the proposal really just ought to include it.
The Core Team agrees with the community that "property delegates" isn't a good name for this feature. First, the feature isn't fundamentally about delegation, it's about giving the property different behavior. Second, it's not hard to imagine that we might someday add a feature that is fundamentally about delegation, i.e. something to make it easier to define storage as an alias for other storage. Finally, "delegate" has an idiomatic meaning in Apple UI programming that's quite different from this. Among the better names suggested in the review:
- "property behaviors", even though that name was already used for a similar-but-rejected feature in the past
- "property wrappers"
- "property decorators"
I'd like to thank the community for its patience and its commitment. I know we've had a lot of proposals recently, and some of them have been contentious, and it can be a lot of work to keep up with Swift Evolution. You really are appreciated; thank you for everything you do to help make Swift a better language.