I am very much in favor of this proposal. It will provide a powerful and unique way to encapsulate common behaviors, eliminating large amounts of boilerplate.
I think we'd all love it if the proposal had a wider scope that could handle more use cases, but I think you've reached a natural stopping point for a single proposal and we can add more features later. In the Swift 3 cycle, we let the perfect be the enemy of the good. We can't do that again.
My criticisms are all with the skin of this proposal:
-
I still don't love the leading
$. If we can manage it, I think an@would provide a nice visual link between the attribute that applies the delegate and the use of the delegate in code. -
I still don't love the name "property delegate" and the attribute and property named with that term. "Delegate" is already a fairly overloaded term in Cocoa programming and I don't think it does a great job of conveying what the proposal is about. "Property wrapper" might be a good alternative, but there are many others.
-
I think we should take some syntactic inspiration from the
@compileTimeAttributeproposal on the horizon. Maybe something like@wrapperAttribute(declarations: .property)? This would make the two proposals feel of a piece while also leaving obvious space for@wrapperAttributes for methods or types in the future.
If these complaints seem shallow, that's because I think the bones of the proposal are excellent. And even if it's accepted exactly as it is, it will be a huge win for Swift users. I'm excited to see what people do with property delegates.