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.
