Dan Korostelev

Yeah that doesn't look too good. That's because ash was the first project I ported when I started learning Haxe. It should be completely reviewed and cleaned up from boilerplate,...

I think we should get rid of GenericListIterator at all and provide strictly typed inlineable iterators for each collection. I'm not sure if I'll find time/motivation to work on that...

Hi! To be honest I didn't use Haxe generics at all. Are they the same as C++ templates? I'll look into it, thanks for advice!

Yep this could be a nice feature, but it may be challenging to implement in an efficient haXe-way (so no realtime overhead, no nodelist duplication, more static checks and stuff)....

I don't really maintain this, so nope, unless someone wants to take it over :)

The idea with the current proposal is already opt-in explicitness implemented through a normal suspending function called `await`. E.g. ```haxe import PromiseAwait.await; function makeRequest():Promise; suspend function someFunction() { var data...

So this basically comes down to a whitelist of suspending functions that are allowed to be directly called. I'm pretty sure this can be implemented on top of this proposal,...

In Kotlin there's a feature called [restricted suspension](https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md#restricted-suspension) that _kind of_ provides something like that - it forbids calling any suspend functions that are not methods of the given "receiver"...

So I looked into [how Kotlin does it](https://github.com/Kotlin/KEEP/blob/master/proposals/coroutines.md#restricted-suspension) and it's pretty simple, I'll describe it in our terminology: - what we have in the proposal right now is the `start`...

> The current proposed design requires different await wrapper functions for different types of Promises, Tasks, etc. Some code to support any kind of task abstraction would be required anyway,...