smol-rs / futures-lite

Futures, streams, and async I/O combinators.
Apache License 2.0
451 stars 26 forks source link

Add `boxed()` and `boxed_local()` for StreamExt and the new `FutureExt` #1

Closed Byron closed 4 years ago

Byron commented 4 years ago

Even though these are easily replaced by the corresponding calls to Box::pin(), having a suffix notation for it (i.e. a.boxed()) was useful enough for it to be used in some portions of prodash.

As the implementation is trivial, I hope adding it is still in the vein of being lite .

ghost commented 4 years ago

Thank you! Just one concern - I have never liked BoxFuture and BoxStream because they're named awkwardly and parametrized over a lifetime that is practically always 'static.

Consider:

let f: BoxFuture<'static, io::Result<TlsStream<Async<TcpStream>>>>;

This is the fully spelled out type:

let f: Pin<Box<dyn Future<Output = io::Result<TlsStream<Async<TcpStream>>>> + Send>>;

Let's remove the lifetime from BoxFuture because it's always 'static:

let f: BoxFuture<io::Result<TlsStream<Async<TcpStream>>>>;

However, note that we have to either import futures_lite::future::BoxFuture or import futures_lite::* and then use future::BoxFuture:

let f: future::BoxFuture<io::Result<TlsStream<Async<TcpStream>>>>;

Having "future" twice in future::BoxFuture is kind of unnecessary, so why not rename to future::Boxed:

let f: future::Boxed<io::Result<TlsStream<Async<TcpStream>>>>;

After all, future::Boxed fits better as the return type of a method named boxed() than BoxFuture! Long story short, I'd prefer to have names future::Boxed, future::BoxedLocal, stream::Boxed, and stream::BoxedLocal and remove the lifetime.

How do you feel about that?

Byron commented 4 years ago

Thanks, @stjepang , that makes perfect sense to me, and I have just pushed the suggested change. Fun fact: When you ask me 'How do you feel about that' I had to chuckle as it's a little bit like Dumbledore asking a young Harry Potter if he wants to do his homework ;). Yes, maybe one day he will realize his potential, but until then he better just do as he is told :D.

It's amazing how certain things, like the original copy-paste implementation of Future::boxed* seemed a bit complex, yet I never questioned it given that it's written by people who probably know so much better.

What I love about your crates is that they show that this isn't always the case, and there is always a way to bring the complex into the realm of simple, to be understood by everyone. So yes, let me express (once again) my gratitude for the work you are doing, it's super valuable to me!

ghost commented 4 years ago

I changed the docs a bit (hopefully they are slightly more helpful now): https://github.com/stjepang/futures-lite/commit/5dd5ad1b86a7bee3597e2a1edb9739afe669edbe

This is now published in v0.1.6