The issue is currently nightly (Mar'23).
Has no .next:
Restore Stream::next. This was removed from the RFC because it prevents dynamic dispatch, and subsequently removed from the implementation. This should be resolved before stabilizing.
Async iterators can still be used - I've read so, but forgot how.
a) This is the state of Async Rust, in Mar'24.
b) Once async iterators are available, we can (should) use them in the code; even if it means nightly - that's fine.
--
Presumably, reading can work by:
poll_fn(|cx| iter.as_mut().poll_next(cx)
-
The two APIs are not related / have a different feel to it - though they could (should!!) be
- Sink is the source of someone's Stream; Stream leads to a Sink
-
One has
<Item=..>, another<Item>. Why? -
Sink is behind a feature option for
futures_util. Why?features = ["sink"]
This means: separating error management from the data flow.
Could we have so that streams can return a value, on completion or failure.
Similar to Akka Streams that has supervision strategies.
Asking for MUCH. But there's need for some kind of pattern for handling when a certain part of a stream pipeline fails - preferably without burdening the prototypes by passing on Result!
p.s. catch_unwind seems to be this, but also notes "This method should not be used for error handling.".
What does that mean by "error handling"?
..whatever they are.
I keep getting this error in Rust Rover EAP:
If there feature was there.. I wouldn't get the error - right?
"Status of inherent associated types" (Feb'21) names this. Been proposed ca. 2014?