Thanks your suggestion. I'm thinking whether this improvement can be made using existing methods. For example, this is one of the ideas for this, creating a single file containing only the definition of a struct and the methods of that struct would be an improvement (little or more). The filename should contains the struct name like 'users_methods.go' or 'users_properties.go'. Or adding comment to make the method groups. Before considering the changes, I want to know more description what part of the current Go syntax makes you difficult to read.

Thanks for your reply.
About the use of screen readers (SR) reading methods is just one of the inconvenience, but take into account the others arguments too.

The main goal of the proposal is to implement a feature to declare the methods receiver in one place to avoid repetition of the receiver identifier and the type of the receiver. It could be like syntactic sugar for the current way of declaring receivers.

Extra advantages.

Another advantage of grouping methods is that the entire block of methods could be folded. Is not good for accessibility (currently I've disabled folding feature) but can be useful for sighted people.

I think people would love more of go if they don't need to repeat the receiver declaration each time, if they have the option to group methods with just one receiver declaration for that group of methods.

Accessibility.

Focusing on this specific point (when using a SR) when I read the code, I don't see the screen. I move and read by lines instead. Since I just see one line at a time, I prefer grouped things (blocks) because is easier for me to relate the tings. Most of times I prefer short things with a few symbols (like "()[]." etc) and I prefer the identifiers as close to the beginning of the line code (that is, ignoring indentation because the cursor is usually placed after the indentation). In fact is one of the things I like from go, identifiers before type definition.

Use case example.

let's see an example about why I consider tedious to define the receiver for each method. I will write a simple code, and then, the text of the voice output when I'm reading the code for each method signature.

Code.

type Student struct {
	Name string
	Age  int
}

func (s *Student) PrintStudentName() {
	fmt.Printf("student name: %s", s.Name)
}

func (s *Student) PrintStudentAge() {
	fmt.Printf("student age: %d", s.Age)
}

func (s *Student) PrintStudentInfo() {
	fmt.Printf("student name: %s, age: %d", s.Name, s.Age)
}

Voice output.

The voice output for each method signature is the following:

func left paren s star Student right paren PrintStudentName left paren right paren left brace
func left paren s star Student right paren PrintStudentAge left paren right paren left brace
func left paren s star Student right paren PrintStudentInfo left paren right paren left brace

As you can see, I have to listen "left paren s star Student right paren" each time I read the method signature. So, reading a code is very verbose and if you sum each time I have to read it, that represents a lot of unnecessary words and symbols because the code needed for declaring methods is very repetitive.

Another inconvenience is that if I want to move the cursor to the method identifier, I need to press control + right arrow 6 times. (using vs code) Compared with just one time when I need to focus the name of a function without the receiver declaration at the begining of the method signature.

If I'm usin a braille display, the identifier in a function is usually at the same place and this is good for readability. But if you add the receiver declaration, the position of the method identifier depends on (the size of the receiver type identifier plus the receiver name).

Conclusion.

An easier readability with SR is just one of the edges of grouping methods related with a receiver. But as you can see in my previous comment, there are many advantages for everyone and not for blind people only.

I know that for now, we can't do anything with the older code.
But it would be great when people start adopting a new way of doing the tings. Better readability, less repetitive code, easier coding, less code to write...

Adding a new keyword is never backward compatible. I don't have much opinion on whether this is a good or bad idea, but I can suggest a syntax which would be truly backward compatible and arguably consistent with existing concepts. This would be to allow methods to use the declaration block syntax available with const and var. Your example would become:

type SomeStruct struct {
	someField any
}

func (p *SomeStruct) (
	GetSomeField() any {
		return p.someField
	}

	SetSomeField(val any) {
		p.someField = val
	}
)

func (v SomeStruct) (
	AnotherMethodByValue() any {
		return v.someField
	}
)

This is backward compatible because, currently, method declarations require a bare identifier to follow the receiver, so the presence of parentheses would indicate a block instead.

Hi @zephyrtronium. I don't mean backward compatibility. I mean that you can continue running older code in new versions, not new versions code in older compilers. Currently, can you run go 1.9 in go 1.4 compilers for example?
I.E. what about type aliases introduced in go 1.9?

How can your suggestion be backward compatible if go expects an identifier after receiver declaration but you are sending a block statement?

I like your suggestion and it's even more easy to read (because you dont use func for each method) but could be harder to implement in the language. And in my opinion, can be a little harder to understand for new GO developers.

I think that this feature should be like syntactic sugar, to help to make it easier to write and read methods with receivers involved. The main goal should be to remove the current code repetition, required for methods with receivers. And the suggested solution is by grouping them in a block, and an initial receiver declaration for that group of methods.

It should not add differences in the final compiled code.

Currently, we can group signature of methods using interfaces, I think that the same thing but for groups of complete methods can be useful. Although is unrelated, because I don't mean to create new types; it should be transparent for the parser.

P.S. Although I said "it's even more easy to read (because you dont use func for each method)" the keyword "func" should be required even in the grouped methods to maintain the consistency between function declarations.

@davidacm
Good points. I took a mental shortcut I had used in the past, but which didn't fit here. 🙂

This proposal seems to make groupMethods a keyword. That is not backward compatible in the way that I use that term, because a statement like groupMethods := 1 would no longer compile. That is, Go code that is valid today would not be valid if we adopt this proposal. That doesn't in itself mean that we can't accept the proposal, but it is something to consider.

Hi @ianlancetaylor, you're right. I wrote the keyword "groupMethods" as an example, it doesn't mean that this keyword should be the word used for this. In fact, I don't like this specific word because that is very long to be used as a keyword.

For me, using a keyword seems to be the easiest way to implement this. But find a good keyword could be very hard, I'm thinking about this since your comment.

So, the suggestion of @zephyrtronium could be a good alternative to start, because that does not require a keyword. is more complex because it would require to recognize a pattern, so the implementation would not be so direct as by using a keyword.
I can't think in a good pattern to group methods. Start it with the keyword func could be confusing because developers could see it as functions inside a function, and will be unclear if the compiled result is the same by using the current way or this proposal. I think that my knowledge of GO is not enough to find a good pattern without using a keyword.
I'm thinking in some alternatives, (E.G. use the func keyword with an additional symbol that indicates grouping (preferably a prefix symbol because the group indication would be recognized immediately by the user) but might not be an elegant solution.

In my opinion the repetition of the identifiers for each method associated with a receiver is tedious and I don't think I'm the only one who thinks that way. But I have tried to present all the arguments why I would like to handle that in a different manner. Surely there are more arguments in favor of unifying the methods binded to a receiver, so it would be good to think together of a good and simple solution.
I'm convinced that allowing grouping of methods bound to a receiver would be a great addition to GO, because of my arguments I wrote in my previous comments. This would solve a lot of things that feel unconfortable in GO.
It can help readability, accessibility, refactoring, code review, code writing, ETC.

Personally, I think this change would lead to code that is harder to read. Today it is fairly simple for me to understand what each variable in the method body is, especially if the method is short (generally good practice). But with this, I'd have to scroll up to the top of the block (which could be arbitrarily long) just to see what the name and type of the method receiver are, leading to similar frustrations to what I experience today with global variables. In languages like Java this isn't an issue because this is a special keyword with a well-defined meaning.

Another issue with this proposal is that in practice the method receiver can either be a pointer or non-pointer, but those could not be in the same group. So for example, MarshalJSON and UnmarshalJSON would either be separated, or would not leverage this feature.

hi @rittneje.

Your comment is a good and very valid point. But this inconvenience can be mitigated following good programming style rules. For example, use the same identifier as a convention for the receiver.
In python for example, that is a very intuitive language to learn, you usually use self to refer to the class, but you could use another name if you want. It's just a recommendation that you can follow or not.
In python although you need to specify self for each method, is not tedious because self is a short identifier and you don't need to write the type of the identifier, that is the problematic part because the type is not of the same size in all cases. In terms of accessibility, in python the name of the method always begin at the same position, because you don't need to add anything before of the method identifier.

In all languages in the world, you can choose between a good or bad standard to write the code. that's why documents of recommendations when writing code exist.
Although is not a forced requirement, it's usually to use just one letter to name the receiver in GO. And is nice, but you can choose to write a long very name, if you want. But if you follow the conventions and recommendations, usually it will be easy to identify if it's a receiver identifier. It's not the same case as global variables, because in global variables a programmer can write N variables, but in go you can write just one receiver for each method. And would be the same in the proposal.

For me, as a blind person, indentation is very important because my screen reader can skip an entire block of certain level of indentation, or go to the start of a code block according it's indentation too, I can skip between levels of indentation in various ways. But although is not a requirement, the 99.9% of developers indent the code. So, even if it's not a forced requirement (except in python) is a very stablished standar.

Your comment has made me see that this proposal represents a small penalty but you get good benefits instead: less repetitive code, fewer changes when updating a code (and therefore shorter and easier to review commits), easier to read and write method signatures , grouped and indented code (if you want to indent) possibility to fold the grouped code related to the receiver.

It will improve the accessibility because of method signatures easier to read for screen readers (voice), easier way to locate method identifiers when using a braille display or when moving by words with the keyboard, because the method identifier for each signature will be at the same position in the distinct lines of the code. And I'm not looking at cases where people use magnifiers. Surely we can find even more advantages than disadvantages.

P.S. I'm not saying that GO has accessibility issues. In the end it's just code and people can adapt. It's more a matter of comfort, intuitiveness, ease, readability, maintainability. In short, it would be a usability improvement in many ways.

All languages should evolve to be easier to understand, read, write and maintain. Repetition is not good in any language, even human languages.

Hi again. I've been thinking in a good way to implement this feature without adding a new keyword. Currently, my ideas hover around extending the functionality of the keyword "func".

One approach could be to use the operator "<-", used in channels, but won't confuse anyone because it will be used in a distinct context. Or add a new operator like "->", the same operator used in C++ to access pointer fields.
With the first operator, I don't see inconvenience, because go already has some operators with two or more functions. For example, the operator "*", used as an arithmetic operator and pointer operator too.

Example:

First, let me to define the example structure:

type SomeStruct struct {
	someField any
}

Example using "->" operator.

// "func->" does not mean a function definition, it means a group of functions with the same receiver.
func->(p *SomeStruct) {
	func GetSomeField() any {
		return p.someField
	}

	func SetSomeField(val any) {
		p.someField = val
	}
}

func->(v SomeStruct) {
	func AnotherMethodByValue() any {
		return s.someField
	}
}

I like this approach because "->" is easy to recognize and the meaning of the arrow right "->" can be related easy with a group of things.

Example using "<-" operator.

the example with "<-" would be the same as above, that just in case if define a new operator were not possible.

But another way could be to use the ">-" symbol after the receiver declaration. To indicate that the specified receiver will be handled by the next methods. Seems very intuitive for me.

// "func->" does not mean a function definition, it means a group of functions with the same receiver.
func(p *SomeStruct) <- {
	func GetSomeField() any {
		return p.someField
	}

	func SetSomeField(val any) {
		p.someField = val
	}
}

func(v SomeStruct) <- {
	func AnotherMethodByValue() any {
		return s.someField
	}
}

Other thoughts.

I prefer the first example (or the "func<-" replacement) because although I used a new operator in the first example, it is very easy to realize that this is not a function definition statement.

When I'm exploring the code by symbols ("control + shift + ." in VS Code) My screen reader reads the receiver part for each method too. Usually, in that kind of structure, the screen reader should read the symbol name directly. But address this issue by the extension of go, with the current implementation of receivers, will be very hard because:

• If the receiver part is removed in that view, since you can write the methods in no particular order, then can be hard to find the required method.
• Group methods by receiver in the view, that would breaks the order of methods and could confuse the reading user.

So, if go were able to implement a feature to group methods, this definitely will help in a lot of good ways for writing and reading code. It would be a great addition to GO. And although we can't do anything with the older code... the new code will be more easy to read, write, maintain, and with more accessibility features. Will be easier to process by parsers, linters and extensions. Will be more structured, with well-defined hierarchies. All those advantages will incentivize developers to use the new functionality of grouping methods by receiver.

While experimenting with some of the ideas discussed above, I tried something like what @zephyrtronium described:

package main

type Foo struct{}

func (f *Foo) (
	Blah() {}
)

Of course I was expecting this to be treated as invalid because the Go specification doesn't allow this syntax today, but the specific error it produced was quite interesting:

./prog.go:5:15: syntax error: unexpected (, expecting name or (
./prog.go:6:12: syntax error: unexpected { after top level declaration

Apparently the parser encountered an unexpected opening parenthesis while also expecting an open parenthesis, which seems curious.

I imagine this specific error message is just a bug/quirk in the parser, but it makes me wonder if this is somehow ambiguous in a way I'm not seeing: the wording of this error message makes me think there's a branching point in the parser here where a name leads down the normal method parsing path whereas an open parenthesis (assuming it had been valid here) would lead down some other path.

If this isn't actually ambiguous, it does seem to be the most similar to the existing pattern of grouping multiple declarations together into a single statement with a shared prefix, as in these other examples:

import (
	"fmt"
	"testing"
)

const (
	Foo SomeEnum = iota
	Bar SomeEnum
)
// (and similarly for the "var" keyword)

// This one seems non-idiomatic, but is still allowed per the spec and
// is included as an explicit example in the current spec text.
type (
	Foo struct{}
	Bar interface{}
	Baz int
)

...it also seems like it is the option which introduces the least additional noise for a screen reader to read through: just one extra "left paren" and "right paren" pair in return for only reading "left paren p star Foo right paren" once across all of the grouped declarations.

@apparentlymart Thanks, filed #56022 for the bad error message. It's not ambiguous. The parser is expecting either a receiver or a name after the keyword func. It just happens to give an error message saying that it expects a receiver even if it already found a receiver.

If we do this, I think we should use the syntax that @zephyrtronium shows in #55863 (comment). Using that syntax would also have the advantage of letting us have a single declaration of receiver type parameters for a generic type.

While we appreciate the accessibility argument, most Go code will continue using the current approach. And there will always be many reasons to define methods in different files, rather than in a single group. In fact, we do not want to encourage people to always define methods in a group, because while that can be more compact, it also encourage people to group together things that are not naturally grouped.

It's also worth considering that a group with many methods means that some of the context—the receiver name—will be far away from the method, obscuring what a name refers to. This would be particularly confusing if the receiver name is also a different name at package scope, which does happen from time to time.

Therefore, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.