On Tue, Nov 25, 2025, at 10:40, Edmond Dantes wrote:
> Hello
>
> > Susie doesn't know anything about the implementation, other than what is
> > defined in the interface. That is literally the purpose of accepting an
> > interface.
> > So it sounds like her only safe option is to restrict her usage of async
> > coroutines to small self-contained pieces of code, and only use injected
> > dependencies and callbacks in the "main" coroutine where they were passed
> > in.
>
> Exactly. This means that for asynchronous logging, a separate
> interface must be introduced in order to guarantee correct behavior.
If we're going to have to recreate some of the most basic interfaces to get
async to work ... does it make sense to seriously consider coloured functions?
As annoying as it would be to refactor so much code, I think we could
realistically provide ourselves escape hatches by not requiring every function
calling `await` to be async?
// non-async functions can still call await, but this just forces a blocking
call to the async function
function i_call_await(): string {
return await someAsyncFunction(); // spawns and blocks until a coroutine
completes
}
// returns Coroutine<string> -- since we don't have generics
async function someAsyncFunction(): string {
return file_get_contents_async('some_file'); // does not block but returns a
coroutine since the function is async
}
// alternative implementation that technically returns
CompletedCoroutine<string>
async function someAsyncFunction(): string {
return await file_get_contents_async('some_file'); // spawns and blocks until
a coroutine completes
}
Just a thought and would mostly just be sugar around the proposed RFC.
— Rob
