> 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.