[withoutboats3]

You don't need move constructors if every future is heap allocated. But then every call to an async function is a separate allocation, which is terrible for memory locality. Some kind of virtual stack would be much better than that (but then you need garbage collection if you want the stacks to be memory-optimized to be small by default).

[anonymoushn]

You could use an actual stack. As I understand it this was not done for questionable reasons relating to borrows of thread-locals. You could also allocate a top-level async function and all of its transitive async callees all at once, if you force the user to put all this information in 1 translation unit. Or you could use a bump allocator specifically for futures used in a certain part of the program, if you're willing to give up using a global allocator for everything. So it seems like there are a lot of options.

[ComputerGuru]

All this is fine and dandy for async web apps but would make things like async-as-state-machine, which powers a lot of rust embedded development, basically a non-starter.

[anonymoushn]

In embedded development it's impossible to use any allocation strategy other than the language constantly calling a global malloc on your behalf?

[ComputerGuru]

Normal async doesn’t require any malloc.

[anonymoushn]

Great! I certainly didn't intend to say that stack-allocated or statically-allocated futures should somehow stop working?

[pcwalton]

If you're allocating a call stack per thread you might as well just use actual threads.

[anonymoushn]

This obviously doesn't work. Maybe you can try refactoring a console emulator that uses its stack switching primitive millions of times per second to use threads instead and let us know how well it runs.

[littlestymaar]

But you lose the async/await syntax (which I'm addicted to because it makes blocking point explicit, like `?` makes error explicit).