proposal: Go 2: permit conversion from []chan int to []<-chan int

[scorsi]

I would like to find a solution to #40010.

To remind the problem is:

func myFunc() []<-chan int {
	var res []chan int
	return res
}

Which result on a Compile error: cannot use res (type []chan x) as type []<-chan x in return argument.

The only workaround is either

• To return a slice of channels without receive-only or send-only type qualifier.
  But it's not dev-friendly, what the dev have to do with a simple chan ? read or write ?.. This is what I choose actually.
• Or to append the channels to a new slice with the right type.

func myFunc() []<-chan int {
	var chans []chan int
        // do your stuff to chans
        var res []<-chan int
        for c, _ := range chans {
                res = append(res, c)
        }
	return res
}

Which is very compute-time consuming and not the right solution too.

[beoran]

What you want is covariance, where if X and Y are assignable, []X and []Y also become assignable ti each other. https://en.m.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)

In the past the Go authors have repeatedly stated that they want to keep the type system simple, and don't want to introduce covariance.

Generics will help a bit here, though, it will likely be possible to have a generic function like that does the copying conversion.

[ianlancetaylor]

It's true that Go has so far rejected covariance, but this does seem to be a special case: a case of adding (or, presumably, removing) type qualifiers, rather than changing types in a more general way. In particular there is no question here of changing the method set, which is one of the reasons for rejecting covariance (https://golang.org/doc/faq#convert_slice_with_same_underlying_type).

[beoran]

Well, if you are willing to consider this special case, then simply allowing a type cast ([]<-chan int)(chans), and presumably also (<-chan int)(ch) would be a backwards compatible feature.

[ianlancetaylor]

Note that (<-chan int)(ch) is already permitted.

[beoran]

Yes, that's correct.

However, I am not really convinced that the argument about changing the method set is very convincing. Already, Go allows certain casts where the method set changes, but not for others with the built in collections of these types.

https://play.golang.org/p/8Pfni3CMXvS

package main

import (
	"fmt"
)

type MyInt int
type MyIntChan chan MyInt
type ROMyIntChan <-chan MyInt

type IntChan chan int
type ROIntChan <-chan int
type ArrIntChan []chan int
type ArrROIntChan []<-chan int
type ArrMyIntChan []chan MyInt

func main() {
	var ch1 chan int
	ch2 := (<-chan int)(ch1)    // This does not change the method set.
	ch3 := IntChan(ch1)         // This changes the method set.
	ch4 := ROIntChan(ch1)       // This changes the method set.
	// ch5 := MyIntChan(ch1)    // Not allowed
	
	fmt.Printf("%v, %v, %v, %v\n", ch1, ch2, ch3, ch4)

	var i1 int
	i2 := MyInt(i1)             // This changes the method set.		
	fmt.Printf("%d, %d\n", i1, i2)	
	
	var a1 []int	
	// a2 := ([]MyInt)(a1)	    // Not allowed.
	fmt.Printf("%v\n", a1)
	
	var cha1 []chan int
	//cha2 := ([]<-chan int)(cha1)// Not allowed
	cha3 := ArrIntChan(cha1)      // This changes the method set.
	//cha4 := ArrROIntChan(cha1)  // Not allowed
        //cha5 := ArrMyIntChan(cha1)  // Not allowed

	fmt.Printf("%v\n", cha3)	
}

Probably similar for maps. Casts that would change the method set of the element of a array, slice, map, or channel are not allowed, but changing the method set for the whole collection, as well as adding a channel restriction to make it read only or write only are allowed.

Perhaps some of these other restrictions could be loosened, especially if no change in the underlying type occurs? As a chan MyInt has the same layout in memory as a chan int, and similarly for maps, slices and arrays of MyInt versus those with int?

[ianlancetaylor]

Let's please not sidetrack this specific proposal into a general one about converting slices of elements with the same underlying type. Thanks.

I'm just pointing out that this specific proposal is not quite like the general case, because it involves only changing type qualifiers in the slice elements. Go has exactly one type qualifier, channel direction, and perhaps it is OK to permit conversions of slices that only change the type qualifier in the slice element type. Or perhaps not, I'm not sure. My only point is that this is different from the general case, in a way that may be relevant.

[beoran]

OK, I agree that a more general proposal would be a separate issue.

However, the point I was trying to make was that Go, as it is now, is consistent in that casts between collections of types that have the same underlying type are not allowed. That's why I thing that an exception just for read only channels would make Go harder to learn with limited benefits.

[scorsi]

The debate about ([]MyInt)(ints) is another one, I'm agreed. Here it's not about underlying type but only about underlying type qualifier.

I'm not sure this is an exception about the casting of underlying type, for me chan int and <-chan int is the same type just it allow or not different things (read-only, write-only or read-write). What I think is that even in read-only or write-only, the channel stay a channel of the same type.

About the consistency, what I suggests is to make the same behaviour for all type qualifier (even if as @ianlancetaylor noticed, it only exists channel direction actually).

This is a subject to debate with the community. Because, of course, people will think that underlying type casting should be accepted if that specific case here is accepted.

[randall77]

This proposal suggests allowing

var x []chan int
y := ([]<-chan int)(x)

But what about

var x []<-chan int
y := ([]chan int)(x)

I think we don't want to allow the latter. So it isn't just about changing type qualifiers. We need the additional restriction that the cast is changing qualifiers in the direction that restricts the allowed operations.

As a separate thought, this proposal assumes that chan int and <-chan int have the same representation. That's true today, but need not be true in some other implementation. I could imagine channels implemented as endpoints, where bidirectional channels are pairs of pointers, one to a read endpoint and one to a write endpoint, and the direction-qualified channels are single pointers.

[bcmills]

In the other direction: if we are going to assume that chan int and <-chan int have the same representation, would that also imply allowing (say) a func() chan int to be converted to a func() <-chan int?