Sounds like something that can be prototyped outside of the Go project to demonstrate its worth.

It could indeed. I've created an external package with the proposed implementation.

I would expect Get() to return (T, error) to account for the failure case. (And likewise the callback would be func(T, error).)

Also, it could be useful to change the signature to Get(context.Context) (T, error) , or at least have a GetWithContext method.

I would expect Get() to return (T, error) to account for the failure case. (And likewise the callback would be func(T, error).)

I think that's unnecessary. Much like a channel, if you want to return an error and another value, just use a struct. Or, if #56462 or something similar got accepted, use that.

Also, it could be useful to change the signature to Get(context.Context) (T, error) , or at least have a GetWithContext method.

I thought of that, but it just seemed like overkill. If you want to use a context, you can just do

select {
case <-ctx.Done():
  // ...
case <-f.Done():
  // ...
}

I see no need to complicate the implementation for an easily handled, and probably unlikely, scenario.

I feel in two minds about this proposal.

I think if it's intentionally constrained to be like a "write once, ready many" channel -- no additional "value add" capabilities such as automatic context tracking, error handling, etc -- then it could be a nice utility helper for a relatively common pattern that would hopefully be easy to understand for anyone who is already familiar with channels.

What's proposed above does seem to meet that criteria: Future.Get is analogous to <-ch, calling the "complete" function is analogous to ch<- ..., and Future.Done compensates for the fact that only first-class channels can work with select to wait for any one of multiple events by exposing the minimal possible channel-based public API.

If this were added then I would expect to use it in a similar way to how I typically use channels today: largely only as an implementation detail inside a library that encapsulates some concurrent work and not exposed prominently in the public API design.

But at the same time, that also reduces the value of it being in the standard library: if I won't typically be exposing Future values in my public API then there's no reason why I need to agree with other libraries about which Future implementation I'm using, and so it's fine to use either an inline implementation or an third-party library to handle this.

If this did start to become a significant part of public-facing library APIs then that's where I start to become more concerned about it, because it seems like that would significantly change the "texture" of Go code using this facility:

It's pretty rare today for a high-level library (as opposed to low-level synchronization helpers) to start an operation in the background and return an object representing the future result. Instead, library functions typically block and expect their caller to start a new goroutine if the blocking is inconvenient. It would be unfortunate if Go ended up in a similar position as some other ecosystems where there are parallel sets of libraries for "blocking style" vs. "async style" approaches to the same problem.

For now then, my conclusion is a conservative "no" vote (also represented in the reactions to the original issue), not because I don't think this would be useful but because I don't think it passes the typical bar for inclusion in the standard library unless we expect it to be broadly used in the public APIs of shared libraries, and the consequences of that concern me. I am curious to see whether and how deedles.dev/syncutil might be adopted in real-world code, though.