{"action":"created","issue":{"url":"https://api.github.com/repos/BurntSushi/chan/issues/12","repository_url":"https://api.github.com/repos/BurntSushi/chan","labels_url":"https://api.github.com/repos/BurntSushi/chan/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/BurntSushi/chan/issues/12/comments","events_url":"https://api.github.com/repos/BurntSushi/chan/issues/12/events","html_url":"https://github.com/BurntSushi/chan/issues/12","id":186696413,"number":12,"title":"[feature request] re-expose try_recv()","user":{"login":"Roguelazer","id":263424,"avatar_url":"https://avatars.githubusercontent.com/u/263424?v=3","gravatar_id":"","url":"https://api.github.com/users/Roguelazer","html_url":"https://github.com/Roguelazer","followers_url":"https://api.github.com/users/Roguelazer/followers","following_url":"https://api.github.com/users/Roguelazer/following{/other_user}","gists_url":"https://api.github.com/users/Roguelazer/gists{/gist_id}","starred_url":"https://api.github.com/users/Roguelazer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Roguelazer/subscriptions","organizations_url":"https://api.github.com/users/Roguelazer/orgs","repos_url":"https://api.github.com/users/Roguelazer/repos","events_url":"https://api.github.com/users/Roguelazer/events{/privacy}","received_events_url":"https://api.github.com/users/Roguelazer/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-11-02T02:21:24Z","updated_at":"2016-11-04T13:30:22Z","closed_at":null,"body":"I'm looking at converting some code from `std::sync::mpsc` to `chan`, and the lack of `try_recv` kind of makes my code ugly. For example, consuming all current items on an asynchronous channel without blocking in std looks like the following:\r\n\r\n```\r\nwhile let Some(item) = item.containing.chan.try_recv() {\r\n    // handle item\r\n}\r\n```\r\n\r\nIn `chan`, this ends up looking like\r\n\r\n```\r\nlet receiver = item.containing.chan\r\nloop {\r\n    chan_select! {\r\n        default => {\r\n            break;\r\n        },\r\n        receiver.recv() -> item => {\r\n             // handle item\r\n        }\r\n    }\r\n}\r\n```\r\n\r\nIf you're in a vaguely-OO context and the receiver is on `self`, this gets even uglier because there are gross contortions required to get a reference to the receiver whose lifetime doesn't spread through the entire method.\r\n\r\nI appreciate that it's cleaner to _just_ have `select` instead of also having the `.try_*` methods, but it seems that it might be more pragmatic to keep both interfaces, especially since it seems like upstream is never going to stabilize Select in `std::sync::mpsc`, so `chan` is going to be increasingly popular for people who want CSP semantics."},"comment":{"url":"https://api.github.com/repos/BurntSushi/chan/issues/comments/258431137","html_url":"https://github.com/BurntSushi/chan/issues/12#issuecomment-258431137","issue_url":"https://api.github.com/repos/BurntSushi/chan/issues/12","id":258431137,"user":{"login":"BurntSushi","id":456674,"avatar_url":"https://avatars.githubusercontent.com/u/456674?v=3","gravatar_id":"","url":"https://api.github.com/users/BurntSushi","html_url":"https://github.com/BurntSushi","followers_url":"https://api.github.com/users/BurntSushi/followers","following_url":"https://api.github.com/users/BurntSushi/following{/other_user}","gists_url":"https://api.github.com/users/BurntSushi/gists{/gist_id}","starred_url":"https://api.github.com/users/BurntSushi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BurntSushi/subscriptions","organizations_url":"https://api.github.com/users/BurntSushi/orgs","repos_url":"https://api.github.com/users/BurntSushi/repos","events_url":"https://api.github.com/users/BurntSushi/events{/privacy}","received_events_url":"https://api.github.com/users/BurntSushi/received_events","type":"User","site_admin":false},"created_at":"2016-11-04T13:30:22Z","updated_at":"2016-11-04T13:30:22Z","body":"OK, so this method already exists, but it's not exposed. Here is its signature:\r\n\r\n```rust\r\nfn try_recv(&self) -> Result<Option<T>, ()>;\r\n```\r\n\r\nThe return type seems a little strange to me. Ideally, it would just return an `Option<T>`, but `recv` already returns an `Option<T>`. Specifically, in the case of `recv`, `None` is returned if the channel is closed.\r\n\r\nAn `Option` nested in a `Result` seems a little unfortunate. Should we instead return a custom enum? e.g.,\r\n\r\n```rust\r\nenum Try<T> {\r\n    Some(T),\r\n    WouldBlock,\r\n    Closed,\r\n}\r\n```\r\n\r\nThat seems more explicit to me."}}
{"actor":{"display_login":"BurntSushi"}}