What’s the practical use case for this in an actual code? I rarely see functions with more than four arguments. Anything that requires more usually means the function just takes a config struct.

If I understand correctly, this proposed feature would make the parameter names chosen in the signature be part of the significant API of the package defining the named function type, whereas today those names are exclusively for documentation purposes and so authors can freely change them if they think of better names later based on user feedback.

I would personally find it surprising for it to be considered a breaking change to select a different name for an parameter in the signature, or to remove the names and use just the types. I worry that lots of package maintainers will make this mistake and learn about this unusual language feature only when they get a bug report saying that a caller's code is now broken.

If the information being elided were syntactically "closer" to the definition that implies that information then I might evaluate this tradeoff differently. For example, I feel good about the ability to omit the type part of a nested composite literal when the type is implied by another composite literal directly enclosing it, but I think allowing such an implication to flow from a package-level declaration into an expression inside an unrelated function -- which might not even be in the same package -- makes it far too easy for changes in one part of a large system to have confusing impact on other subsystems far from the declaration being changed, which is a maintenance hazard.

Based on my understanding of the proposals process, I think this proposal should be based on the language change proposal template.

Not identical, but very similar to #30931.

see also #21498

What’s the practical use case for this in an actual code? I rarely see functions with more than four arguments. Anything that requires more usually means the function just takes a config struct.

Yeah you are right. The example I wrote was an extreme example for the sake of illustration. The actual code I wrote which led to opening of this issue looked something like this (it's long and filled with type params): func(expectations functional.Expectations[int, float64], indices *tensor.Dense[int], retVal *tensor.Dense[float64], right, left func(int, float64) (int, error)). I had 16 of these makeFoo equivalents to write.

Whether or not this is a code smell (the function signature probably is, I'm still in exploration mode), you gotta admit that with package names and long type names and potentially instantiations of generic data types, you will end up with very long function signatures. And yes while names can be shortened or aliased out, it's not always the most prudent thing to do.

I ended up writing a bit of elisp to generate the skeleton for my 16 makeFoo functions. But this is not ideal. Not everyone uses a programmable text editor.

Additionally, there's the issue of consistency. In Go, values of almost all the named composite types (arrays, maps, slices, structs, channels) can be instantiated by using its name, e.g.

type MyChan chan int
type SoC struct{ C MyChan }
type ListOfSoC []SoC
type MyMap map[int]ListOfSoC

... 

C := make(MyChan)
s := SoC{C}
l := ListOfSoC{s, s, s}
m := MyMap{0: l}

There's one composite type that is missing from having this ability: function types. For the sake of consistency, we should allow values of function types to be instantiated with their names too

For the sake of consistency, we should allow values of function types to be instantiated with their names too

You can do f := myFunc(nil). It's only illegal if you want to define the function body, which seems like a decent restriction since you need to name the arguments to use them.

If #21498 were accepted, I think that would be a good enough solution.

This means a cosmetic change in the argument names of a func type definition becomes a breaking change, potentially in a far away place

this is an awful proposal from a maintenance/comprehension/reading stand point.

"features" that do nothing but save keystrokes have exponential downsides when trying to maintain the code later, or read it to learn what it is doing. explicit is better than implicit. and competent IDEs like GoLand will auto generate the mapping by pressing CRTL+ALT+ENTER. whatever time implementing this would be much better spent on something way more useful like allowing arbitrary struct to be comparable by specifying a function for the struct.

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)