The latest information on `reasync`?

I saw this comment the other day:

and felt inspired to make a thread in which the people who know more than I could perhaps give some insight into the current situation with the concept of reasync. Are there doubts about its usefulness? If use cases are what's missing I've got plenty:

Example of real use case for `reasync`

The mutated(by:) method defined below is extremely convenient for a certain style of programming in which expressions are progressively built-up by stacking method calls, like in SwiftUI.

protocol ExpressionErgonomic { }
extension ExpressionErgonomic {
    func mutated (by mutation: (inout Self) throws->()) rethrows -> Self {
        var copy = self
        try mutation(&copy)
        return copy
    }
    
    func mutated (by mutation: (inout Self)async throws->()) async rethrows -> Self {
        var copy = self
        try await mutation(&copy)
        return copy
    }
}

With reasync this would be written as just:

protocol ExpressionErgonomic { }
extension ExpressionErgonomic {
    func mutated (by mutation: (inout Self)async throws->()) reasync rethrows -> Self {
        var copy = self
        try await mutation(&copy)
        return copy
    }
}

Has it just been a matter of strategically deferring implementation costs, but that reasync is sure to be added at some point?

Thanks in advance for the time taken to provide any information!

22 Likes

Would be great to see this. Amongst other things (typed throws, primary associated types), it seems like this would be a prerequisite to including an AsyncSource dual to AsyncSequence within the standard library.

@reasync @rethrows
protocol AsyncSource {
  ...
  func send(_ element: Element) async throws
  ...
}
3 Likes

+1. This and typed throws (or at least some way to get (a) primary associated type(s) for AsyncSequence) are IMO the two pieces that I think are most sorely missing when looking at the current API surface of Swift's standard library.

9 Likes