proposal: Go 2: allow second argument to close as alternative to futures

[DeedleFake]

I was reading through #17466 and I realized that future-style functionality already exists with channels via close(). The only real difference is that a closed channel always returns a zero value of its element type. Therefore, I propose adding a second, optional argument to close() which, if specified, causes receives on the channel to return the value given, rather than the zero value.

For example, the following would print 3 twice:

c := make(chan int)
close(c, 3)
println(<-c)
println(<-c)

I fiddled around with the runtime and compiler in an attempt to get it working myself as an experiment to see how viable it is. I'm not particularly familiar with a lot of the internals, but I managed to get it working in the runtime with minimal effort. I had a bit more trouble with getting the compiler to accept a second argument to close(), but I know that that's plausible as there are other built-in functions that do similar things.

Advantages

• Doesn't break Go 1 compatibility guarantee. It would require a tweak to the internal structure of channels, but that's not something that's guaranteed to stay the same, so that should be fine.
• Provides 1:N one-time broadcasting capability, as futures do, as well as the ability to receive the 'sent' value multiple times from the same channel. It basically makes channels act exactly like futures, without requiring any new types or standard library API.

Disadavantages

• close() is a bit awkwardly named for this type of thing, even if it does make sense in terms of it being a channel. If this is accepted, it might be a good idea to do something a bit different for Go 2.

I'm sure there are other problems, but that's why I'm proposing it. I'd originally posted this as a comment on the previously referenced issue, but it's quite different from what was proposed there and no one responded, so I decided to make it a separate proposal.

[DeedleFake]

Another potential issue that I had thought of but forgot about when writing the proposal is dealing with the reflect package's ability to close channels. The only way I can think of to implement it would be to add a second Close() method with a slightly different name to reflect.Value, which is less than ideal.

[extemporalgenome]

This would make debugging harder, at least for a while. Today, if you see a flood of 3s coming out of a channel you wouldn't go look for a close. You can still implement futures easily enough by having a 'done' channel with companion value field (or values, as you'll usually want to support an error result).

[bcmills]

The only way I can think of to implement it would be to add a second Close() method with a slightly different name to reflect.Value

(reflect.Value).Close is already weird, in that it's a method and not a package-level function. In contrast, the copy built-in is a function (reflect.Copy), new is a function (reflect.New), and make is a whole family of functions (reflect.MakeChan and friends).

It's not at all obvious to me why close, len, and cap are special enough to warrant being methods instead.

[nhooyr]

@bcmills maybe that should be another fix for Go 2.

[daskol]

@DeedleFake This has really awkward sematics. It would be better either to introduce explicit future type or to implement it in the standard library. There are at least two reasons for that.

The first one is that you modify API of channel that it is actual standard. It will wonder people who work with fifos in Linux for example. This is why I think that future type is more suitable.

The second one is that your proposal brings some overhead to common communication and synchronization primitive. Also it is not quite obvious for me how it will affects GC and code generation due to counter 3. In my view there is lack of future. However, it is highly unclear how futures should be in language. So, we could implement following interface into standard lib as initial step.

type Future interface {
	Set(value interface{})
	Get() interface{}
	Wait()
}

[ianlancetaylor]

The only advantage I see over a future implemented in a package is that this approach is compile-time-type-safe. I hope that in Go 2 we will have some form of generics which will permit writing a compile-time-type-safe future package. If we have that, this seems like an odd change to the existing channel semantics. If we don't have that, we can revisit this.