You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/// async-stream ///pubfnstream<T,F,Fut>(f:F) -> implStream<Item = T>whereF:FnOnce(Yielder<T>) -> Fut,Fut:Future<Output = ()>,{/* ... */}pubfntry_stream<T,E,F,Fut>(f:F) -> implStream<Item = Result<T,E>>whereF:FnOnce(Yielder<T>) -> Fut,Fut:Future<Output = Result<(),E>>,{/* ... */}// This macro will shadow the yielder with a function that borrows from a local.//// It will panic if called after the first poll or from a different stream.#[macro_export]macro_rules! start_stream {// $yielder must be of type Yielder<T>($yielder:ident) => {/* ... */};}/// Usage ///let stream = async_stream::stream(|yielder| asyncmove{// Must be called in the first poll, otherwise the stream will panicstart_stream!(yielder);yielder(1).await;yielder(2).await;yielder(3).await;});
I'm pretty sure this would be sound. Ergonomically, we'd lose the nice for await and yield syntax as well as the ability to use ? in regular streams (although users can always use a try_stream and then flatten the results if they want something like that), but we'd also gain the ability to specify the type of stream with turbofish syntax. I think it might be nice to support both versions in the library, depending on users' preferences. Any thoughts on the design?
The text was updated successfully, but these errors were encountered:
My implementation in the linked PR is indeed not zero cost — but async streams are in general not really zero cost, but since the cost is a single pointer and it wasn’t zero cost to begin with, it is probably unproblematic.
I've been thinking that it would be possible for this crate to provide an API that doesn't use proc macros at all, which has a couple of benefits:
The API could look like this:
I'm pretty sure this would be sound. Ergonomically, we'd lose the nice
for await
andyield
syntax as well as the ability to use?
in regular streams (although users can always use atry_stream
and then flatten the results if they want something like that), but we'd also gain the ability to specify the type of stream with turbofish syntax. I think it might be nice to support both versions in the library, depending on users' preferences. Any thoughts on the design?The text was updated successfully, but these errors were encountered: