Introduce as_box

[Ekleog]

(whoops, pressing “enter” in the title bar apparently sends the issue, sorry for the blank mail)

I was just thinking that having Box<Either<Foo, Bar>> was inefficient in two ways: first, it allocates, and then on each poll it does a conditional jump for the Either. So I was thinking that it would be possible to introduce as_box as a method on the Future trait, with the obvious default implementation as_box(self) -> Box<Future> { Box::new(self) }, but that could be overridden by eg. Either to actually perform the Either unwrapping immediately, and actually generate either Box or Box.

Not sure that'd bring much, just dropping an idea :)

Anyway, thanks for your work!

[daboross]

I think this would suffer from the same problems the old .boxed() method suffered from. Specifically, there's a large ambiguity whether we want to create Box<Future + Send + 'static> or just Box<Future + 'static> (see #228).

Maybe this would be different with the new tokio design? I'm not sure.

[Ekleog]

Hmm indeed, sounds like it'd be a bad idea for API design reasons, all that for likely-minor performance gain. Thanks! :)