On Tue, Nov 25, 2025, at 12:03, Bart Vanhoutte wrote: > Op di 25 nov 2025 om 11:36 schreef Rob Landers <[email protected]>: > > > > > > 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? > > > > I have worked with coloured functions in PHP when Fibers were not > around and the developer experience is very bad. Before PHP 8.1; every > function I wrote would be coloured by either accepting or returning a > Promise<sometype> (which is made worse by the fact there's no > generics). > > Since PHP 8.1; I can use Fibers and implement a widely spread > Interface in an async way. Currently, if I want to use an SDK client, > the first thing that I check is `composer.json` to find out what HTTP > client it uses. If it accepts a PSR-18 ClientInterface I use a small > wrapper around ReactPHP's Browser that awaits a Promise and I'm set. > We've been talking about shared state and possible breaks in backwards > compatibility, but I must say that in reality it's not something that > I find being in the way very often. Like I've made it seem before, if > there's any serious breaks in backward compatibility (not the order of > log lines that might be different from the sync implementation) I > would at that point just document the change and release a new major > version of a library. That is a lot less painful imo than working with > coloured functions. > > Best Regards, > Bart
Looking higher up the thread, you'll see that Larry also proposed something similar. I'm not saying everything needs to be coloured. In other words, there is no "Promise" object that always needs to be handled. Adding an "async" to the function makes it return a Coroutine, that can be awaited. This is a bit different than Generators where you can only return a Generator. The return type stays as you'd expect it to be if it weren't async. Then, when/if you call await on this coroutine, and we're not already in a coroutine, it will spawn one for us, blocking until it returns. If we are already inside a coroutine, then it blocks until the coroutine completes. Then you have coloured functions when you want them, but can call them without having to change your code or "infect" your code with async/await. Its literally just sugar over the currently proposed RFC, as you'd have to return Coroutines and await them anyway, but this is actually more type-safe. — Rob
