Please Don't Mangle the Function Signature, re Go2 generics proposal

txt.md

For gosh sakes, don't make us read code with the scrutiny of a compiler :-) A type declaration after a function name is confusingly similar to an argument list.

Which witch is which?

• func Stuff(type T Something)(input T) error { ... }
• func Stuffed(input Somethingelse) error { ... }

C++ style is fine; variations on paren placement can be considered

• (type T, U) Something // line break or semicolon
(type V) // more on next line
func Stuff(input T, more U, other V) error { ... }

And consider simple function aliases for callers

• func TypedStuff Stuff(TypeA, TypeB, TypeC)
const TypedStuff = Stuff(TypeA, TypeB, TypeC) // alternatively
err = TypedStuff(x, y, z)

I think the type keyword is a good clue that you've got a set of type parameters. I have to say that I think the syntax is really good - it doesn't introduce any new keywords or lexical tokens and it's quite readable and memorable. When writing some generics code using this syntax, I didn't get confused, and I think that's a good sign.

@rogpeppe, the trouble arises when you have a file of generic and non-generic functions. If it's all one or the other, your perception of text adjusts to that context.

Also a larger number of parameters and/or returns, each specified in the type list with a contract, becomes unwieldy for a single line.

Absolutely agree, this kills the whole simplicity and readability of the language which made it efficient and so beloved.
If adding generics, then better implement as parametrised packages.