Just to clarify a few things:
-
The restriction for a property delegate type to have a single generic type parameter is now lifted? (Edit: I checked the tests in the new implementation and can confirm this restriction is gone.
)And thank you so much for allowing explicitly providing generic type parameter list on the property delegate (
@Lazy<Int> var property: Int) - I assume that will also play nicely in a generic context.(Edit: You replied in the other thread, but I didn't get a notification.)
-
Now that property delegates are custom attributes, do you have a vision what can/should happen next with the
IBprefixed attributes? Those are part of the language if I'm not mistaken but they should really be part ofUIKit/AppKit. One thing that concerns me a little is that@IBOutletrequires the type to be an optional. As a property delegate it could be similar toDelayedMutable. -
Can you also clarify in the proposal how the API surface marked with property delegates will look for imported API?
I assume
@propertyDelegateattribute itself will be always visible on public types (trivial), but what about properties annotated with a concrete delegate.Is this a correct assumption?
// module A @Lazy public var foo: Int = 1738 // for the API user the above is exposed as following // when module A is imported public var foo: Int = 1738 -
One other thought: I hope the tooling can teached to jump to the property delegate type declaration when for example in Xcode you would cmd + click on the property delegate.
Small correction, BehaviorRelay is part of RxCocoa which is build as a common extension of RxSwift. That makes BehaviorRelay a safe wrapper around BehaviorSubject that has similar semantics except that it also can be disposed or error out. You can change RxSwift's BehaviorRelay replays to RxCocoa's BehaviorRelay replays. ;)
Other than that I love the direction the proposal is going now, it shaped into something really swifty.