proposal: spec: permit directional variants of named channel types

[robpike]

Consider this program:

package main

import (
	"fmt"
)

type Foo chan string

func main() {
	c := make(Foo, 1)
	c <- "gotcha"
	fmt.Println(<-c)
}

All is well. Now try to declare a direction for a Foo:

package main

type Foo chan string

func main() {
	var x <-Foo
}

// or

func x(c <-Foo) { }

This doesn't parse, but it's reasonable to expect it would and maybe, perhaps with parenthesization, easy to define without ambiguity. (A directional Foo with element type Foo could be tricky.)

Reported on twitter.

[cespare]

Isn't this kind of like doing

type MyInt int
var x uMyInt // Is this a uint?

i.e., I wouldn't expect this to work at all.

[dsnet]

I'm tentatively marking this as a language change, unless you are suggesting that the current parser is not matching the written spec (in which case this is a bug).

[robpike]

I think it's a language change.

[griesemer]

Definitively a language change, possibly backward compatible.

But why would we want to allow such a thing? It makes the direction arrow an operator on types, and only on channel types. And it only can make a bidirectional channel a read-only channel. What if I wanted to create a write-only channel? In the current design of the language <- arrow is really part of the channel syntax pattern, not a separate operator when it comes to channel types. The syntax is simply not compositional (we cannot interject a <- into the middle of a channel type).

I don't see why this would be worth the effort.

[leonklingele]

This is requesting similar syntax to #22189.

[robpike]

I'm not saying it is or is not worth the effort, but it definitely a flaw in the design that one can declare read-only channel types only if they are unnamed. I can't think of another property of the language that works like this, for instance that changes the possible types acceptable by a function.

[ianlancetaylor]

See also #23415.