Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: Go 2: permit directional variants of named channel types #21953

Open
robpike opened this issue Sep 20, 2017 · 12 comments
Open

proposal: Go 2: permit directional variants of named channel types #21953

robpike opened this issue Sep 20, 2017 · 12 comments
Labels
LanguageChange Proposal v2 A language change or incompatible library change
Milestone
Proposal

Comments

@robpike
Copy link
Contributor

robpike commented Sep 20, 2017 •
edited

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.
@robpike robpike changed the title spec: problem parsing named channels spec: problem parsing named directional channels Sep 20, 2017
@cespare
Copy link
Contributor

cespare commented Sep 20, 2017

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 dsnet added LanguageChange v2 A language change or incompatible library change labels Sep 20, 2017
@dsnet
Copy link
Member

dsnet commented Sep 20, 2017

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
Copy link
Contributor Author

robpike commented Sep 20, 2017

I think it's a language change.

@griesemer
Copy link
Contributor

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 leonklingele mentioned this issue Oct 9, 2017
Closed
@leonklingele
Copy link
Contributor

This is requesting similar syntax to #22189.

@robpike
Copy link
Contributor Author

robpike commented Oct 10, 2017

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 ianlancetaylor changed the title spec: problem parsing named directional channels proposal: Go 2: permit directional variants of named channel types Mar 20, 2018
@gopherbot gopherbot added this to the Proposal milestone Mar 20, 2018
@ianlancetaylor
Copy link
Contributor

See also #23415.

@ianlancetaylor ianlancetaylor added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 20, 2018
@bcmills bcmills mentioned this issue Apr 19, 2018
Closed
@mccolljr

This comment was marked as off-topic.

Sign in to view
@ianlancetaylor

This comment was marked as resolved.

Sign in to view
@mccolljr

This comment was marked as off-topic.

Sign in to view
@ianlancetaylor

This comment was marked as resolved.

Sign in to view
@griesemer
Copy link
Contributor

An possible problem with this proposal might be ambiguity of the parse tree (requiring type information to resolve it). To be investigated.

@gopherbot gopherbot removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Aug 16, 2019
@gopherbot gopherbot added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Sep 3, 2019
@ianlancetaylor ianlancetaylor removed the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
8 participants
@cespare @ianlancetaylor @robpike @leonklingele @dsnet @griesemer @mccolljr @gopherbot