fix false must_use warning on JoinHandle

[rschmukler]

Removes the must_use requirement on the JoinHandle

Motivation and Context

The must_use requirement is a bit misleading, since the JoinHandle is the
result of a future being spawned, and thus the originating future will be
polled to completion, whether or not the JoinHandle is polled.

This seems like it may overlap with some of the changes in #73, where it may be desirable to instead use a RemoteHandle - but since there is some open discussion, this seems like a worthy (and simple) change.

Another option might be to add a .forget() method which consumes the JoinHandle directly, and is thus a bit more explicit.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[stbuehler]

I'd recommend replacing it with RemoteHandle directly; this would change the semantic a little (RemoteHandle must actually be used; if dropped without calling forget it will cancel the future) - basically the opposite direction of this pull request.

[stbuehler]

I.e. I'd suggest this: master...stbuehler:replace-joinhandle

[rschmukler]

@stbuehler I'm not opposed to that direction at all, but it is worth noting that that behavior is different than how existing runtimes (tokio, namely) currently operate. Do you want to open a PR and perhaps let the maintainers decide which way they want to go? I'm mostly indifferent.

[stbuehler]

@rschmukler Done. I'm curious though which part in tokio you mean - spawn in tokio doesn't actually return something useful right now.

I think futures would be the more appropriate place to make this decision - I don't care much which way it goes either, but I think using types from futures is the right way.

[rschmukler]

@stbuehler Sorry, I actually remembered the incorrect behavior. Your change is actually very consistent with the futures::sync::oneshot::spawn (0.1.21) API (which has a SpawnHandle that behaves exactly as a RemoteHandle). My inclination is to emulate that behavior since it seems least surprising - making your change, in my book, the preferred route to take. I'll close this, although the maintainers are welcome to take it if they want it.

[rschmukler]

Reopening per the discussion in #80

[yoshuawuyts]

Thanks heaps! We'll make this part of the next Runtime release!