# A case study for \`reasync\` **URL:** \ **Category:** Discussion\ **Created:** [April 24, 2023, 10:40pm UTC](https://forums.swift.org/t/a-case-study-for-reasync/64590 "2023-04-24T22:40:48Z")\ **Posts on this page:** 1\ **Showing post:** 27
**Author:** ![kiel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kiel/32/1392_2.png) [@kiel](https://forums.swift.org/u/kiel)\ **Post date:** [June 21, 2023, 4:35am UTC](https://forums.swift.org/t/a-case-study-for-reasync/64590/27 "2023-06-21T04:35:31Z")
To forestall any communication issues, this message is not addressed to the OP directly but to the general forum reader. First, in our own code base, we have `asyncMap` and `asyncCompactMap` because we'd like to await values within the closures given to `map` and `compactMap`. If we did not have these, we would have to write some small but annoying boilerplate: create a result array variable (not constant), reserve its capacity and loop over and act on each element. Another time I found myself trying to asynchronously `reduce` but bumped into the absence of an async overload, so I wrote the boilerplate and refactored it to use variables and loops. While we do have functions to cover these, I am an idiot. Was I supposed to extend `Sequence` to do this? Should I use `underestimatedCount` to reserve the resulting array's capacity or was that a pointless operation? How will this scale over large collections? Should it be inlinable? Is some other dependency going to introduce this and collide with my own implementation? etc. Second, there was a [recent pitch](https://forums.swift.org/t/pitch-with-functions-in-the-standard-library/65716) whose [implementation](https://github.com/apple/swift/compare/main...aggie33:withSwift:main) is literally repeated/duplicated. Add that to the [ton of overloads](https://forums.swift.org/t/a-case-study-for-reasync/64590/10) some other library authors have to provide. In the absence of overloads and third party, generic functions duplicating logic, developers would be required to use variables instead of constants. Doing this introduces complexity into reasoning about code and limits intuitions about code since, in order to understand the logic in some scope, we now also need to check the variable is not mutated anywhere else within it (I'd guess that kind of check would almost always result in a "no, it's not mutated anywhere else"). So it seems pretty straightforward that there's a need for `reasync`. I guess the reason a proposal has not surfaced is because compilers are hard and it would not be a starter task? --- _[View the full topic](https://forums.swift.org/t/a-case-study-for-reasync/64590)._