proposal: constraints: add ReadOnlyChan and WriteOnlyChan

[ianlancetaylor]

The currently accepted proposal for the constraints package (#45458) adds a constraint Chan. In #47319 (comment) @Merovius points out that does not support read-only and write-only channel types. This proposal is to add new constraints

type ReadOnlyChan[Elem any] interface { ~<-chan Elem }
type WriteOnlyChan[Elem any] interface { ~chan <- Elem }

[uluyol]

Should these be

type ReadOnlyChan[Elem any] interface { <-chan Elem | chan Elem }
type WriteOnlyChan[Elem any] interface { chan <- Elem | chan Elem }

instead? That way func f[E any, C ReadOnlyChan[E]](chans []C) would accept both a slice of <-chan and a slice of chan.

[smasher164]

Is there a reason why the Chan constraint uses the approximation element ~chan Elem, while ReadOnlyChan and WriteOnlyChan don't?

[ianlancetaylor]

@smasher164 Thanks, fixed.

[andig]

Should these be

type ReadOnlyChan[Elem any] interface { <-chan Elem | chan Elem }
type WriteOnlyChan[Elem any] interface { chan <- Elem | chan Elem }

instead? That way func f[E any, C ReadOnlyChan[E]](chans []C) would accept both a slice of <-chan and a slice of chan.

Isn't a chan always a <-chan? I don't think you can restrict- even today- a chan argument to be read-only?

[Merovius]

@andig Yes, you can. By assigning it to <-chan. after that, any write-operation on it becomes invalid and you can't assign it back to chan. https://play.golang.org/p/GSu7Inzp2QY

[Merovius]

@andig Ah, I think I understand what you mean. You can't restrict it so that only a <-chan can be passed, it is always possible to pass a chan (as chan is assignable to <-chan).

But, it's still useful for a function to declare that it will only do read or write operations on a channel - both as a signal to the caller and to get compiler-checks that the function doesn't do it. That's what's meant here.

[andig]

@andig Ah, I think I understand what you mean. You can't restrict it so that only a <-chan can be passed, it is always possible to pass a chan (as chan is assignable to <-chan).

But, it's still useful for a function to declare that it will only do read or write operations on a channel - both as a signal to the caller and to get compiler-checks that the function doesn't do it. That's what's meant here.

Absolutely. I was trying to point out that { <-chan Elem | chan Elem } is redundant to { <-chan Elem }

[Merovius]

As an example: In this code, Map declares that it only reads from the channel that you pass in and that the channel it returns can only be read from. That's useful. But, Map now doesn't work with type MyChan chan int.

I'm not 100% convinced that we need that. For example, AFAIK there currently is no way for a function to declare that it takes a read-only version of MyChan. It just seems to me, that if we need constraints.Chan, than we should also have this ability. IMO it is more important to declare that a channel can only be read or only be written, than it is to enable us to work with custom channel types.

TBQH, I'd probably rather do away with constrains.Chan for now. The only reason I ever used defined channel types was if they had very specific semantics - for example, I might use a buffered type Semaphore chan struct{} as a semaphore. But in those cases, that defined type probably shouldn't be used with generic channel functions. So, while I'm convinced of constraints.Slice and constraints.Map, I'm far less convinced of constraints.Chan.

[Merovius]

@andig No, as @uluyol points out, while chan T is assignable to chan <- T, it is not identical, which matters for composite types like []chan T, which isn't assignable to []chan <- T.

[ianlancetaylor]

I'm withdrawing this proposal in favor of #48424.