- Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely. Property delegates represent an important generalization of the language and its core access patterns and will enable a leap forward in the kinds of functionality that framework authors provide to their clients.
- What is your evaluation of the proposal?
-1, but I must qualify this heavily.
- Does this proposal fit well with the feel and direction of Swift?
The idea of a delegating property is one of those things that I think is so clever and useful that it is inevitable that it will find its way into Swift. It will clearly enable a new level of integration with frameworks that provide conceptually complex behaviors on top of existing types that, up until now, have required hacks or DSLs to achieve. One of the things I especially love about this feature is that it allows us to lower the conceptual entropy of consuming and interacting with behavior-oriented frameworks by allowing the framework author to shoulder the burden of implementation entirely - the wealth of really cool examples bear this out in spades. That's a really good place to be for a feature.
The reason I have to vote it down, then, is because its syntax is conceptually heavy, ugly, and does not fit the language. My concerns stem entirely from my belief that we have all the tools and concepts we need to put this feature into user's hands while also minimizing the amount of new syntactic capital we have to burn to introduce it into The Next Swift.
First, the use of
@propertyDelegate to mark types. Swift uses @-tributes to signal compiler directives which does fit with requirement number one:
- The property delegate type must be defined with the attribute
@propertyDelegate . The attribute indicates that the type is meant to be used as a property delegate type, and provides a point at which the compiler can verify any other consistency rules.
In particular, the last sentence which indicates that we may emit additional diagnostics while verifying the structural integrity of a property delegate than we would otherwise for a plain aggregate. However, it's the second rule that concerns me
- The property delegate type must have a property named
value , whose access level is the same as that of the type itself. This is the property used by the compiler to access the underlying value on the delegate instance.
We have a way to signal these kinds of requirements in the language already: a protocol. We could bless a
PropertyDelegate protocol into the standard library and teach the compiler to perform any additional structural checks a conformance would require. That hypothetically involves special-casing its declaration in order to fit requirement number one, but I doubt it would involve more special-casing than implementing the attribute.
But that's just an attribute. I think the majority of my concerns are about the syntax-ization of user-defined types in what was previously a namespace for compiler-only concepts.
By doing so, we've effectively lost the ability to introduce new @-tributes without having to go through a source-compat morass. This is no longer relevant: see this edit). More than that, the concept is so out of left field for this language where other compiler-level directives accept user-defined identifiers/values. It makes me think that we could have spelled this
var x: T
var x: T
This hews closer to existing attributes and directives (
@available(...), etc.), reads cleaner ("x has type T delegating to Atomic"), and signals clearly that the user intends for delegation. The proposal even provides similar syntax as a future direction.
Again, I have to qualify this: I think there is room in the language for a discussion of user-defined attributes, especially with respect to runtime introspection. However, I strongly believe we do not need this proposal to drive them forward if we already have the language design elements we need to retain its functionality.
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I think this feature is pretty unique in its stylization. To express it, most other languages with meta programming facilities would probably use those. A functional language might choose to express this with a (state) monad plus some additional modality. Since Swift does not have those things, it makes sense that we would provide a standard in-language expansion.
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I've been following along with this idea on and off since Joe's first Property Behaviors proposal.