Attached stream compatibility

Existing "detached" stream:

trait Stream {
    type Item;
    
    fn poll_next(
         self: Pin<&mut Self>, 
         cx: &mut Context<'_>,
    ) -> Poll<Option<Self::Item>>;
}

Probable shape of an attached stream trait:

trait AttachedStream {
    type Item<'a>
    where 
      Self: 'a; // don't ask
    
    fn poll_next(
         self: Pin<&mut Self>, 
         cx: &mut Context<'_>,
    ) -> Poll<Option<Self::Item<'_>>>;
}

Interconversion, such that every stream is automatically an attached stream. This impl must be created at the same time that

impl<S> AttachedStream for S
where
    S: Stream
{
    type Item<'a> = S::Item;
    
    fn poll_next(
         self: Pin<&mut Self>, 
         cx: &mut Context<'_>,
    ) -> Poll<Option<S::Item>> {
        Stream::poll_next(self, cx)
    }
}

Implications:

• If you are able to do so, and you consume a stream, you probably want to consume an "attached stream"
  • When are you able to do so? So long as you process each item before you move on to the next one.
  • So if we had some kind of for-loop integration, for example, it would probably want to work with an "attached stream" trait.
• Frequently people want to spawn off parallel work or tasks, and that requires a detached stream

Complications and considerations:

• The "automatic conversion" impl might not work because if you have other impls like
  • impl<T> Stream for Box<T> where T: Stream
  • impl<T> AttachedStream for Box<T> where T: AttachedStream
  • this is a coherence conflict for Box<impl Stream>, so presumably it will fail the coherence rules too
  • resolving this would require either an explicit "wrapper" step or else some form of language extension
  • same applies to Iterator