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: make generic parentheses declaration order consistent with array bracket declaration order #36533

Closed
gertcuykens opened this issue Jan 13, 2020 · 5 comments
Closed

proposal: make generic parentheses declaration order consistent with array bracket declaration order #36533

gertcuykens opened this issue Jan 13, 2020 · 5 comments
Labels
FrozenDueToAge generics Issue is related to generics LanguageChange Proposal v2 A language change or incompatible library change
Milestone
Proposal

Comments

@gertcuykens
Copy link
Contributor

gertcuykens commented Jan 13, 2020 •
edited

https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md

Can we maybe just reorder the generic parentheses like array brackets order please?
So everything is exactly the same as the current contract proposal just reordered a bit.

package graph

contract (Node, Edge)G {
	Node Edges() []Edge
	Edge Nodes() (from, to Node)
}

type (type Node, Edge G) Graph struct { ... }
func (type Node, Edge G) New(nodes []Node) (Node, Edge)*Graph { ... }
func (g (Node, Edge)*Graph) ShortestPath(from, to Node) []Edge { ... }

// Instead of this
contract G(Node, Edge) {
	Node Edges() []Edge
	Edge Nodes() (from, to Node)
}

type Graph(type Node, Edge G) struct { ... }
func New(type Node, Edge G)(nodes []Node) *Graph(Node, Edge) { ... }
func (g *Graph(Node, Edge)) ShortestPath(from, to Node) []Edge { ... }

Basically following the same order as array's get declared [5]int

Related to: #36177 but yet another suggestion in case it wasn't suggested before

EDIT: Iteration of this proposal (see comments) to something like this to separate generics completely from regular go code

package graph

contract (Node, Edge)G {
	Node Edges() []Edge
	Edge Nodes() (from, to Node)
}

type (type Node, Edge G) ( Graph )
func (type Node, Edge G) ( New )
const _ = (Node, Edge) Graph

type Graph struct { ... }
func New(nodes []Node) *Graph { ... }
func (g *Graph) ShortestPath(from, to Node) []Edge { ... }

General generics issue: #15292 (see comment below)
@gopherbot gopherbot added this to the Proposal milestone Jan 13, 2020
@ianlancetaylor ianlancetaylor added generics Issue is related to generics v2 A language change or incompatible library change LanguageChange labels Jan 13, 2020
@ianlancetaylor
Copy link
Contributor

I don't understand why this is better. Since we are using parentheses, and since type parameters are much more like non-type parameters than they are like anything else, consistency with function declarations and calls seems more useful than consistency with array declarations and uses.

@gertcuykens
Copy link
Contributor Author

gertcuykens commented Jan 13, 2020 •
edited

For me it makes it more readable to distinguish generic syntax. Especially this two lines messes with my head and predict I will be making regular typo's for example forgetting the word type or use , instead of )(

type Graph(type Node, Edge G) struct { ... }
func New(type Node, Edge G)(nodes []Node) *Graph(Node, Edge) { ... }

Also I believe alignment is important

func (type Node, Edge G) New(nodes []Node) (Node, Edge)*Graph { ... }
func (type Node, Edge G) Delete(nodes []Node) (Node, Edge)*Graph { ... }
func (type Node, Edge G) ShortestPath(nodes []Node) (Node, Edge)*Graph { ... }
func (type Node, Edge G) Find(nodes []Node) (Node, Edge)*Graph { ... }
func (type Node, Edge G) Add(nodes []Node) (Node, Edge)*Graph { ... }

func New (type Node, Edge G) (nodes []Node) *Graph(Node, Edge) { ... }
func Delete (type Node, Edge G) (nodes []Node) *Graph(Node, Edge) { ... }
func ShortestPath (type Node, Edge G) (nodes []Node) *Graph(Node, Edge) { ... }
func Find (type Node, Edge G) (nodes []Node) *Graph(Node, Edge) { ... }
func Add (type Node, Edge G) (nodes []Node) *Graph(Node, Edge) { ... }

@beoran
Copy link

beoran commented Jan 14, 2020

Hmm, I am not sure if I like this or not, however would then this syntax also be allowed?

func (type Node, Edge G) (
        New(nodes []Node) (Node, Edge)*Graph { ... }
        Delete(nodes []Node) (Node, Edge)*Graph { ... }
        ShortestPath(nodes []Node) (Node, Edge)*Graph { ... }
        Find(nodes []Node) (Node, Edge)*Graph { ... }
        Add(nodes []Node) (Node, Edge)*Graph { ... }
)

If so that could make writing generics easier, although it might make reading them harder again.

@gertcuykens
Copy link
Contributor Author

gertcuykens commented Jan 14, 2020 •
edited

Your suggestion looks nice to have some sort of decoration ability like const (...) and var (...) Actually if you would be able to find some sort of syntax that just completely separate generic stuff from regular go without mixing it, even if it would be more verbose it's worth the price of clarity.

func (type Node, Edge G) (
        New
        Delete
        ShortestPath
        Find
        Add
)

func New(nodes []Node) (Node, Edge)*Graph { ... }
func Delete(nodes []Node) (Node, Edge)*Graph { ... }
func ShortestPath(nodes []Node) (Node, Edge)*Graph { ... }
func Find(nodes []Node) (Node, Edge)*Graph { ... }
func Add(nodes []Node) (Node, Edge)*Graph { ... }

And if you extend it with something like const _ = (Node, Edge) Graph you would get complete separation.

package graph

contract (Node, Edge)G {
	Node Edges() []Edge
	Edge Nodes() (from, to Node)
}

type (type Node, Edge G) ( Graph )
func (type Node, Edge G) ( New )
const _ = (Node, Edge) Graph

type Graph struct { ... }
func New(nodes []Node) *Graph { ... }
func (g *Graph) ShortestPath(from, to Node) []Edge { ... }

@ianlancetaylor
Copy link
Contributor

Upon discussion with Go 2 proposal review committee, we would like to fold this issue into the general generics issue #15292. Please also feel free to add a link to this issue to https://golang.org/wiki/Go2GenericsFeedback. We don't think it will be helpful to keep multiple generics syntax issues open simultaneously, spreading the discussion to too many different places.

-- for @golang/proposal-review

@griesemer griesemer mentioned this issue Jan 28, 2020
Open
@tooolbox tooolbox mentioned this issue May 2, 2020
Closed
@golang golang locked and limited conversation to collaborators Jan 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge generics Issue is related to generics LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
4 participants
@beoran @gertcuykens @ianlancetaylor @gopherbot