# A case study for \`reasync\`

**URL:** <https://forums.swift.org/t/a-case-study-for-reasync/64590>\
**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:** 10

<div class="post-metadata">

**Author:** ![stephencelis](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stephencelis/32/2675_2.png) [@stephencelis](https://forums.swift.org/u/stephencelis)\
**Post date:** [May 12, 2023, 5:40pm UTC](https://forums.swift.org/t/a-case-study-for-reasync/64590/10 "2023-05-12T17:40:12Z")

</div>

> [@ZPedro](#):
>
> In light of some echoes that the need for `reasync` is still doubtful for some, I would like to present you a case study that demonstrates this need. The short version: I can already obtain the bulk of the functionality with a `sed` script, functionality which my code requires in order to get out of the libdispatch ghetto.

Are there really doubts out there? We've had to define a ton of overloads in our projects to support async and non-async contexts. Our [Parsing](https://github.com/pointfreeco/swift-parsing) package also already leverages `@rethrows` to propagate a parser's ability to `throw`, and we'd love to provide similar `@reasync` functionality.

---

_[View the full topic](https://forums.swift.org/t/a-case-study-for-reasync/64590)._