A couple of other random thoughts:
-
I feel like the first implementation of this really needs to have access to the enclosing self, and later versions can add options without it for optimization-sake if necessary
-
There needs to be a way (at least planned) for delegates to constrain the Types that they can be used with as well as the properties of the enclosing type it can be placed on. I had a suggestion here using associatedTypes, but other ideas can work as well
-
We need to have a plan for how these will compose in the future, even if the implementation will come much later. We don't want to paint ourselves in a corner...
-
We should have a plan to allow parameters in the attribute (e.g.
@Delegate(foo: 1, bar: "")). Are those inits? Some other form of declaration? We don't have to implement it now, but we should know where we are headed. -
We should allow something like
@MyDelegate(using: myStorage)to declare custom storage with a programmer defined name. The built-in storage should be unnamed and inaccessible (except for some mechanism for surfacing shared properties on the property). I.e. Delegates should be able to actually delegate... -
I don't think we can wait to have an answer for access rules with the current design. If the storage were private/fileprivate by default we might be able to, but with internal we will be exposing a lot of unwanted surface whenever we use this feature. Furthermore, when you think about it, the real problem isn't whether to expose the storage or not, but that we really want to expose only a few methods of the delegate and keep the rest private to the enclosing type. That is something our current access system can't quite spell. My suggestion was to have a syntax that exposes specially marked methods to everyone with access to the property, and for access to other parts, you would create the storage yourself. Another answer could be to have annotations which expose some methods externally and others only to the enclosing type.
-
I'd really prefer to see this spelled as a protocol (even if it requires a little compiler magic) with the methods that need to be implemented spelled out. I think it would also make the composition and constraint issues mentioned above much easier to solve.