@dignifiedquire can you perhaps share why having e.g. usize::max_value() as the upper bound wouldn't work here? That would allow storing 18 quintillion messages before blocking, making it effectively unbounded.

use async_std::sync::channel;
let (sender, receiver) = channel(usize::max_value());

I haven't been closely involved with the channel implementation. But my understanding is that making a queue effectively unbounded versus guaranteed to be unbounded requires very different implementations. Which in turn require time to build and maintain.

Off the cuff the only thing I can really come up with for completely unbounded channels is that the signature for send could be synchronous (since it's always guaranteed to succeed).

task::spawn(async {
    dbg!(receiver.recv().await);
});

sender.send(b"some data"); // notice: no .await needed here.

This seems possibly useful when trying to communicate from sync -> async code. But given we already have task::spawn_blocking, and a new executor, I'd say we have our bases for sync -> async pretty well covered already.

So in conclusion, this is not to say there aren't any valid uses for unbounded channels. But what I think would be most helpful here is a clear motivating use case that is clearly best implemented through unbounded channels.

I think I could probably work with simply setting a very large limit. My only concern with this would be, does the implementation do any preallocation based on this? because if so that would make this use very risky, as I definitely do not want to pay the cost of allocating billions of entries, when in reality only a 100 or so are ever in there.

@dignifiedquire you're entirely right; we do preallocate and that indeed fails at higher numbers.

I have a use case where each Sender gets 1 guaranteed slot, just like the mpsc channel in futures but without their shared buffer. I use each Sender only once as a way to propagate an error message to some supervisor process, and for that they can send synchronously.

Since all Senders are cloneable, the channel is theoretically unbounded, but its actual size is determined by the application at runtime as Senders are created and dropped. I think it is better to use a linked list in this case.

Closed by #827