There needs to be a way to combine the effects of try_recv and recv_opt

[mstewartgallus]

Before the latest changes at #10830 I could write if port.peek() { match port.try_recv() { ..., now I cannot write equivalent code. One possible solution would be to have a method (let's call it try_opt) that returns an enumeration consisting of either a result or an indication of an empty port or a an indication of a closed port. This solution feels kind of ugly to me though so I'd appreciate suggestions on better solutions.

cc: @alexcrichton

[alexcrichton]

The semantics that you are asking for I don't believe have ever existed. Am I correct in assuming that you want something like:

enum TryValue<T> {
    Empty,
    Disconnected,
    Data(T),
}

fn try_recv(&mut self) -> TryValue<T>;

We have never had a method of attempting to receive a value and simultaneously knowing whether the channel is empty or disconnected. Your previous code is easily mappable to today's semantics, so I'm a little unsure on what you're attempting to do. Does the example I have capture what you'd like to learn from a call to try_recv?

[jdm]

I don't think the replacement described is equivalent to what was lost, which is the ability to peek at a port and discover whether it has a value ready to receive.

[alexcrichton]

old peek + old try_recv is the same thing as today's try_recv, I'm not understanding what the requirement is here, or there's a misunderstanding to what the functions do today.

[jdm]

Ah, my mistake. I apparently internalized the old semantics of try_recv, despite complaining about them all the time.

[mstewartgallus]

Today's try_recv can't tell if the chan on the other side was dropped. So old peek + try_recv is not the same.