Receiver is already re-exported, but its associated error types are not. As a result, users who call Receiver::recv() must add flume as a direct dependency to their Cargo.toml just to access those error types.
In one of my projects, for example, I'd like to implement From<RecvError> for my own error type. Because RecvError isn't re-exported, I'm forced to depend on flume directly.
Since Receiver is already re-exported here, could we also re-export its associated error types (e.g. RecvError, RecvTimeoutError, TryRecvError, etc.)? That would make the public API more self-contained and avoid requiring downstream crates to depend on flume solely for the receiver's error types.
Receiveris already re-exported, but its associated error types are not. As a result, users who callReceiver::recv()must addflumeas a direct dependency to theirCargo.tomljust to access those error types.In one of my projects, for example, I'd like to implement
From<RecvError>for my own error type. BecauseRecvErrorisn't re-exported, I'm forced to depend onflumedirectly.Since
Receiveris already re-exported here, could we also re-export its associated error types (e.g.RecvError,RecvTimeoutError,TryRecvError, etc.)? That would make the public API more self-contained and avoid requiring downstream crates to depend onflumesolely for the receiver's error types.