Closed richardhozak closed 4 months ago
@johanhelsing thoughts?
I guess I'm ok with it but I think it's not necessary
The receive
is non-panicky already, and we have .is_closed
to check if the socket is closed now. Would the developer need to know if the channel is closed with try_receive?
I've always thought the return of the underlying socket is somewhat poorly designed because it returns Ok(None) when the channel is closed and Err(TryRecvError) when it's open but there aren't messages. Our API was meant to be less confusing.
I also think the result is confusing and we shouldn't lock it in by exposing it publicly.
I also think we create a more confusing api by having both receive and try_receive, when their difference is not that one is panicky and the other is not.
Yeah, if I remember correctly what i was trying to solve is to send messages as they are being received, which would probably be handled better by splitting channel into its components (rx, tx).
Adds try_receive function to socket and channel as a counterpart to try_send for those that want to avoid Vec allocation and handle the messages as they arrive.
I adjusted the docs for
receive
function, so people can tell the difference of these functions.