TRACK.md

TRACK

Async Iterators (remains unstable)

• std::async_iter
• Tracking Issue

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)

Unified, nice API for Stream and Sink

• 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"]
  

Error management policy for streams

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"?

"Inherent Associated types"

..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?

My own ticket @ mio-serial

• "How close is Source to a Stream?"