proposal: Go2: allow assigning chan chan struct{} to <-chan chan<- struct{} (nested channel direction auto-conversion in general)

[faiface]

Hello!

This surprised me recently. This is perfectly possible

var ch1 chan int
var ch2 <-chan int
var ch3 chan<- int
ch2 = ch1
ch3 = ch1

Assigning a bi-directional channel to a uni-directional is done without any conversions. And it makes complete sense, there is nothing preventing it.

However, it is not possible when a channel is inside another structure. Examples:

var a struct {
    ch chan int
}

var b struct {
    ch <-chan int
}

b = a // compile error

Note that a and b have anonymous types. The conversion is impossible, although nothing is preventing it.

My specific use-case is a cancellation-confirmation channel. I have a goroutine that I want to cancel and I want that goroutine to report the successful cancellation back. Thus, I pass it a channel of channels. The cancellation signal is a confirmation channel. After a successful cancelation, the goroutine sends a confirmation signal. Like this:

func f(cancel chan chan struct{}) {
    confirm := <-cancel
    close(confirm)
}

func main() {
    cancel := make(chan chan struct{})
    go f(cancel)

    confirm := make(chan struct{})
    cancel <- confirm
    <-confirm
}

Now, I want to restrict the channel directions on the cancelation channel passed to f (f can't cancel itself and so on). So, logically, I change the f's signature like this:

func f(cancel <-chan chan<- struct{}) {

Playground here: https://play.golang.org/p/YTcUnisWHg .

But, this doesn't compile, giving:

tmp/sandbox898600353/main.go:10: cannot use ch (type chan chan struct {}) as type <-chan chan<- struct {} in argument to f

There is no reason why this wouldn't compile. It's just that compiler doesn't auto-"convert" (convert is in quotes, since this is merely a compile time feature, it doesn't really affect any compiled code, or runtime behaviour) channel directions structurally recursively.

I propose it should do it recursively.

Thanks,
Michal Štrba

EDIT: fixed playground link

[ianlancetaylor]

Marking as Go2 since we are not doing language changes right now.

[faiface]

I want to make this proposal for Go 1. This is a tiny, completely backwards compatible change that is just removing an unwise, unnecessary and artificial limitation.

[ianlancetaylor]

I'm sorry, I mistyped my comment (I've edited it to correct it). We are not doing language changes right now.

This change looks tiny, but I think it's more complicated than it seems. We have to decide how to handle cases like

type S struct {
    f func(chan <- int) (<- chan int)
    c chan <- <- chan int
}

Maybe it's simple but in effect it's similar to assignment rules for the const qualifier in C, and people are still regularly confused by that (e.g., http://c-faq.com/ansi/constmismatch.html).

[faiface]

I was thinking about a recursive assignability definition right now, but that comes with complications, because however I tried to define it, it enabled things like this:

var a []int
var b []interface{}
b = a // would pass, bad thing

But, the problem is solvable in an easy way, although one might argue that it's a little ugly. The thing is to redefine type identity of channels from this:

Two channel types are identical if they have identical value types and the same direction.

To this:

Two channel types are identical if they have identical value types and the same direction or if they have identical value types and at least one of them is bidirectional.

This change in the spec would allow what I'm asking for and would prevent things like assigning []int to []interface{}. Also, the change is really simple.

It's possible this change has some gotchas, but I haven't come up with any yet.

[faiface]

With the above change, this line could be removed from the spec:

x is a bidirectional channel value, T is a channel type, x's type V and T have identical element types, and at least one of V or T is not a named type.

[faiface]

I just realized that my example/use-case is actually trivially solvable by rewriting this:

package main

func f(cancel <-chan chan<- struct{}) {
	confirm := <-cancel
	close(confirm)
}

func main() {
	cancel := make(chan chan struct{})
	go f(cancel) // compile error

	confirm := make(chan struct{})
	cancel <- confirm
	<-confirm
}

to this

package main

func f(cancel <-chan chan<- struct{}) {
	confirm := <-cancel
	close(confirm)
}

func main() {
	cancel := make(chan chan<- struct{}) // the arrow right here
	go f(cancel) // passes just fine

	confirm := make(chan struct{})
	cancel <- confirm
	<-confirm
}

However, this still might be useful in more complicated scenarios.

[bcmills]

This proposal assumes that the in-memory representation for chan and chan<- is identical. That's true today, but is it really something we want to bake into the language?

[faiface]

@bcmills That's a fair point and I actually no longer feel like this proposal is a good idea. First, I've been able to solve my problem as I described above. Second, all situation imaginable where this would be useful seem like bad code with duplications.