Thanks for your answer. Here's a more realistic example. Say we have a file.close() function that returns a Future<Void>, indicating when the close is complete. Now we want to make a Future for closing a list of files:

    let fut = Future<void>::new();
    let v = vec![file, file2, file3];
    for file in v.into_iter() {
        fut = fut.and_then(file.close());
    }

Is this possible with this API, or would the assignment to `fut` break because we now have a different type?

With traditional Futures I'd expect this to look like a sort of linked-list of closures (definitely lots of allocation). What does it end up looking like under the hood with zero-cost Rust futures?

You are correct in assuming that the assignment would be a type error.

Similar to other languages, you'd have to allocate. In rust, it would probably look like:

    let mut fut: Box<Future<()>> = Box::new(Future<()>::new());

and then

    fut = Box::new(fut.and_then(|| file.close()));

As discussed elsewhere in this thread, the most direct translation of that code would also be a linked list of futures, but I don't see an alternative for that sort of structure in general (i.e. every scheme for this sort of asynchrony will have a dynamic chain of allocations).

However, the library does provide various abstractions that can abbreviate certain patterns and do them more efficiently than otherwise, e.g. http://alexcrichton.com/futures-rs/futures/fn.collect.html for this case.

Hmm... Shouldn't iterators be turned to streams?

Like this:

    fut = v.into_iter().map(|file| file.close()).into_future();