>>22
Seems it would take a shitload of work; converting all local variables of coroutine functions into thread-local globals, etc.
Globals, what?! You stuff the coroutine's state inside the stack frame of the function that calls it (within
something(), in my example). The compiler could insert whatever boilerplate is needed to make this work,
so that the programmer no longer needs to. At the moment, I have to make structs for any coroutine I write, and pass these around. This is annoying.
The point is, coroutines have already been implemented several times at the library level, they have been proven useful by the numerous other languages that support such a feature, it would not be thoroughly difficult to add in compiler support for the feature, and it would make for much cleaner code for applications that currently rely on libraries to accomplish the same thing (not to mention applications which use kludges to work around the lack of natively supported coroutines).