As for the `self`/static thing: The problem there is that because the

and_then

block will be run off-thread, there are no guarantees that the object referred to as

self

actually exists which that callback in scheduled.

thanks for the description! that makes sense -- i guess i'm not familiar with the futures impl to say why that can't be worked around (not easily -- but with some special interface, maybe)

You're right that async/await would make the problem go away, because the

await

means that

self

must still be on the stack when the function is done executing.

is that the complete definition of what await means in rust? like a join point that requires

self

to be on the stack? / is there a better intro than just reading the rfc

I haven't actually read the RFC, but my assumption (possibly false) is that any async call which is awaited on will be able to be treated under the assumption that its enclosing scope exists throughout the async execution, and that nothing below it on the stack will move

ok that's great

Yes, ish. The Arc wrapping means you can clone the Arc and move the cloned Arc into the closure, which guarantees that the wrapped thing exists in memory, and that the Arc itself can exist on the stack when needed

that makes a lot of sense

(but in the non-self case, wrapping in an Arc is what we do to reference things from e.g. multiple futures)

i understand why i can't Arc &self, but can that be gotten around with e.g. a top-level wrapper function that Arcs an instance of the trait?

The reason you can't Arc &self is because you can't move it. You can Arc self.

ok, that makes sense. i was under the impression there was some specific restriction imparted by the &self parameter for some reason

Nope, just that is a reference, so you can't move it. Exactly the same as why you can move self into a future but you can't move &self into a future :)