A future is just a special case of an observable.  Honestly I'd prefer if 
an observable was built-in the language like a channel. You could use it 
like a channel in selects and the like, but with the possibility of 
receiver observables to be closable. When the list receiver observable is 
closed, the sender could stop producing new values.

On Sunday, October 16, 2016 at 3:40:32 PM UTC+3, Sokolov Yura wrote:
> "future" is commonly used synchronization abstraction.
> It could be implemented in a library, using mutex, channel and interface.
> Example: 
> https://github.com/Workiva/go-datastructures/blob/master/futures/selectable.go
> But obviously, semantically future is just a channel with buffer of 
> capacity 1, but receivers do not pop
> value from a buffer, but instead every receiver receive same value. And 
> "filling" future awakes all
> receivers simultaneously, similar to "closing of channel".
> So I propose to introduce "future" as a same internal type as a "channel".
> It will share representation and lot of code with buffered channel (of 
> capacity 1).
> https://github.com/golang/go/issues/17466

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to