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.

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).

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.

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

@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()
}

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.