jjl
jjl
Hrm, I think the following style of api is possible without needing unsafe: ```rust impl Sender { pub fn reestablish(&self) -> Result } ``` And similar on the Receiver side....
Sure it's possible. Take a look at the WIP - the two halves use a pointer internally. That we happen to allocate it with Box::new is incidental - we can...
Ok, current plan is to base the new Sender and Receiver on the following type to hold a channel: ``` pub enum Holder; ``` I don't know this extra option...
Still not sure exactly sure in which way you want to reuse it. In my working copy, we now have three different means of reuse: * Sending a message no...
I consider this will be fixed with #18 where I've added 3 different ways to reuse hatches. Now would be an excellent time to feed back on that PR.
> * I think we should wrap the `Flags` in an additional newtype struct, so that we can easily mark `flags` (the struct field) on `Sender` and `Receiver` as `pub`,...
Correct me if I'm wrong, but I think broadly, you don't dislike the public api. The internal API is incredibly up for grabs. Here are a few things we could...
I have mostly been working on the (forthcoming shortly) [async-spsc](https://github.com/irrustiible/async-spsc) this week, which offers a bounded alternative. I am wondering whether I should just put them both into async-spsc to...
I'm thinking no at the current time.
ok, the options are gone and so are a bunch of potential branches thanks to some neat bit fiddling. the code is also somewhat shorter and easier to read.