> you //never// get to decide unless you wrap it in a specific form (async\run > or async\async, in this RFC), which ironically colors the function.
You're wrong, it does *not* color the function: spawning a new fiber does not make the code running it async: it is always async, regardless of whether you use async() or not, but when not using async(), it's simply the only async execution flow running. > can't think of any way around it. My biggest issue with this RFC is that it > results in **multiple** colors: FiberHandle, Future, and Resume. You misunderstand again, colors are not objects or classes, colors are special and annoying keywords (red, blue, await) that must always be added to call functions of the same color (red, blue, await). The FiberHandle is literally just a handle associated with the execution flow spawned with async(), it is not in any way associated with the spawned function, nor it is required in any way to invoke the spawned function. Adding colors to functions makes async unnecessarily complex to use, for no good reason at all (no, forcing developers to explicitly know if a function is async or not is not a good enough reason, when I write code I want to get things done, when I want to parallelize execution of something I use go/async(), when I don't, I couldn't care less about what the function does inside, and I especially do not want to do a lot of hoop jumping to use it or use other common patterns like functional composition). Again, take a look at how nicely golang handles concurrency with colorless functions: php fibers weren't the first to do it. Regards, Daniil Gentili.
