-
-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate .observe()
#71
Comments
Since I see the point to get rid of dead wood and streamline the API, I see a strong benefit of using .observe() and that is the |
Would it make sense to extend the AsyncStream implementation with a |
I wanted the main method to be simple, because from extensive use, I almost never needed the old value. However, I do agree we should support providing the old value somehow. Maybe a For now, you could use these utilities: extension AsyncStream {
func withPrevious() -> AsyncStream<(previous: Element?, current: Element)> {
.init { continuation in
Task {
var previous: Element?
for await element in self {
continuation.yield((previous, element))
previous = element
}
continuation.finish()
}
}
}
func withPrevious(initialPreviousValue: Element) -> AsyncStream<(previous: Element, current: Element)> {
.init { continuation in
Task {
var previous = initialPreviousValue
for await element in self {
continuation.yield((previous, element))
previous = element
}
continuation.finish()
}
}
}
} The obvious benefit of having support built-in is that the previous value would be non-optional. |
.observe()
when target is macOS 10.15+?.observe()
.updates()
is better in every way. Having two ways to do the same is also confusing. We cannot remove.observe()
for a long time, but maybe we could add availability annotations so that apps that target macOS 10.15+ (and equivalent iOS/tvOS/watchOS) gets a deprecation message.The text was updated successfully, but these errors were encountered: