Futures-rs: Rename forget to ensure.

[Stebalien]

When I first saw the forget method, I immediately assumed that this was a way to cancel the future (forget about it). While I understand this was named after the std function mem::forget and it means "don't clean this is up but let it finish", assuming that the user will know about this relatively obscure std method is probably not a good idea.

Personally, I recommend renaming it to ensure like the python method asyncio.ensure_future as it seems to do something fairly similar.

[aturon]

Agreed on the name -- I like ensure! Though it's a little unclear to me what the ultimate fate of this method should be...

[alexcrichton]

Yeah I agree that forget isn't exactly the greatest name, it's already showing its age as it was originally intended for something completely different! I agree though with @aturon that we should likely figure out the final story for this method first though before tweaking it.

[dwrensha]

detach() maybe?

[chrivers]

Maybe .background()? Or do you think it gives too much of a kernel scheduler vibe?

[alexcrichton]

We've now since removed forget, so no longer an issue!

[nabijaczleweli]

xD

[Stebalien]

Out of curiosity, is there a new way to say "complete this future in the background"?

Specifically, it would be nice to have some form of dynamically sized (with an optional maximum?) unordered version of Stream::buffered that just completes futures returned from a stream as fast as possible. That is, some way to asynchronously dispatch requests and then handle them in order of completion. As far as I can tell, this doesn't exist.

Note: I'm asking because this feature allowed for an inferior version of that primitive through channels (forget a future and have it reply back through a channel when done).

[aturon]

@Stebalien The problem with forget is it wasn't really "in the background"; the future execute on whatever thread last happened to wake it up. Part of the move with executors is to have a much more clear picture of _where_ futures are being executed.

So, when you say "in the background", what do you have in mind?

[Stebalien]

@aturon I need a way to drive an unbounded number of futures at the same time. I didn't actually like how forget worked as I'd prefer to be able to choose where the futures are completed but it "worked".

Basically, I need something like select_all but I need it to take a stream, not an iterator, because I don't have a bounded number of futures. I'll write up a full report (and maybe implement it) after turning in my thesis...

[orthecreedence]

@alexcrichton I've updated futures-rs in my project and am now seeing that .forget() has been removed, but what is it replaced with? I removed all the .forget() calls in my project, but now I'm getting

warning: unused result which must be used: futures do nothing unless polled, #[warn(unused_must_use)] on by default

in all the places it was removed. How do I actually drive futures forward now? I've looked into executors and tasks in the docs, but I can't find an obvious way to run a future chain.

[orthecreedence]

Oh, actually I see in some places you do

let future = ...;
thread::spawn(move || {
    future.wait();
});

However this seems to run the future chain on the new thread, not the thread the future is created on. Is there a way to execute a future equivalent to what .forget() used to? Thanks!

EDIT: Nevermind, see https://github.com/alexcrichton/futures-rs/issues/332