Remove a box from future, and add future::unwrap

[erickt]

This patch removes the box that holds the forced value, which seems unnecessary to me now that moves work well. Along with that I added a way to unwrap the forced value to match option and result.

The one change I'm not positive about is erickt@ae8253c#L0L140. @nikomatsakis: Your name is attached to this change. Does this look right?

[graydon]

The removal of the box seems ... safe-ish to me. Or rather, it seems like it is as safe as the existing code. But that existing pattern looks to me like it becomes unsafe if you add an unwrap() call. Specifically, get_ref looks like it lies about having something that stays alive as long as the future (the unsafe block there). This is not a bad approximation when futures are monotonic from evaluating => forced. But once you can reset one, all bets are off. Consequently I think this should possibly be done at a different layer; or else get_ref removed and changed to a version that takes a callback and does not widen the reference lifetime. I'll tinker with it.

[graydon]

Oh. There's already with. There's a lot of redundancy in this module! I'll tidy it up.

[graydon]

Hm Hm! The more I think about this the more unusual it seems. What's the point of a future that resets itself? You can only read it once, it's equivalent to a port. Also, you're not resetting it here, you're setting it to Evaluating; that means it's wedged and will fail if anyone tries to read it again. I think this is overall not the approach you want; with() for read-access and get() for copy-access are the thing we want. I'll open a separate pull req to tidy those up (removing redundancy) and close this. Reopen if you disagree.

[erickt]

(Reopening...) I still think this could be pretty useful, it would in effect be a one-shot port. Also, future::unwrap isn't resetting the future, it's consuming it since the future isn't copyable. Evaluating is just an intermediate state to protect against forcing a partially forced future. Perhaps using something like mutable::Mut or std::cell is better than this intermediate state.

#4023 is related.

[nikomatsakis]

FWIW, this change looks safe to me.

[brson]

I agree unwrap is safe and should probably exist, though I can't think of a use case where I would prefer future + unwrap over a pipe::oneshot.

[erickt]

I wasn't aware of pipe::oneshot, which seems to be almost identical to futures with an unwrap. Can we merge them? Is there any advantage to keeping two very similar constructs?

[brson]

The difference is that futures contain a value and pipes produce a value, but they are very similar (and I think the preferred way to create a future now is probably from a oneshot pipe, which also incidentally acts as a 'promise' - if nobody sends the Future value then requesting the value fails).

I do think they have different use cases.

The thing that is making Futures unuseful to me is that they are not Const. For the things where I need futures the most I need them to be sharable. Conceptually I need an ARC<Future>.

[graydon]

@erickt is there any reason to keep this open, given pipe::oneshot and the cleanup over in #4023?

[erickt]

Nope, closing.