Description
Motivation
I would describe the general motivation for reasync as the need for consistency: when some code needs to be in some cases part of an async task because it may delegate to an async function, and in some cases part of a "sync task" (i.e. rely on the architectural stack provided by a thread) for whatever reason, but otherwise needs to behave consistently, maintain the same invariants in particular. More specifically, I would mention the case of a recursive function when for whatever reason within at least one async call stack of that function we might need to further the recursion of the same function in a sync way, whether in a subtask or not. An example of such a situation is the attached project, where reasync is simulated by preprocessing the source file with sed.
Solution
Syntactically, as described in the future direction in the original async/await proposal: same as rethrows but applying to async instead of applying to throws.
Implementation-wise, as described too: have two compilations and two entry points, including everything that entails (e.g. include the two entry points to be resolved later when a function type passed as parameter is reasync).
Alternatives considered
For the need of keeping in sync (no pun intended) two functions, one async and one not, not much else will do the job.
The least awful workaround so far is a sed script that duplicates a source file while removing the async and await keywords (and altering the function names):
sed -E -e 's/ async//g' -e 's/await//gi' -e 's/Async/PseudoReasync/g'
Additional context
Full case study on the forums of the need for reasync in the code of the attached project.