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
IB
prefixed 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@IBOutlet
requires 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
@propertyDelegate
attribute 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.