Consider closing stream if reader was dropped

[Pzixel]

Consider following code:

use futures_util::SinkExt;
use futures_util::StreamExt;
use tokio_tungstenite;

let Ok((ws_stream, _)) = tokio_tungstenite::connect_async(url).await.unwrap();
let (mut write, mut read) = ws_stream.split();
drop(read);
write.send(tokio_tungstenite::tungstenite::Message::Text("Hello").await.unwrap();

It executed without errors. Meanwhile channels notify writing end if reading end was closed:

use std::sync::mpsc::channel;

fn main() {
    let (tx, rx) = channel();
    drop(rx);
    tx.send(1).unwrap(); // panic on err unwrap
}

I think that in most (all?) cases when reading end of WS connection was closed there is no point of keeping writing end alive and writes there should return error. Right now users are likely to implement some sort of let mut is_reader_closed: AtomicBool which isn't ideal.

[daniel-abramov]

These are different things:

• channel() creates 2 channels where you can send to one counterpart and retrieve the sent data via the other counterpart (tx -> rx).
• split(), on the other hand, is a helper method that splits existing Self: Stream + Sink into 2 counterparts. This is not identical to the channel(), because what you send to the Sink counterpart is not forwarded to the Stream counterpart, i.e. you don't retrieve the same things via the rx, but rather you can read from the underlying stream and write to the underlying stream (tx -> stream_tx, stream_rx -> rx). It's possible to read and write separately. One part does not need the other to exist.