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)

Well, my sentiment is a little harder: I like the 'simple' function signatures we have in Go today and don't like adding anything to them. Using the same bracket type twice is obviously making things harder to read and understand. So far we have

1. func keyword
2. type to bind function to (name and reference vs. value)
3. function name
4. input parameter list (name+type)
5. return parameter list (mostly just types)
6. start of function body (opening curly bracket)

Everything within one line. Looks complex enough for me. I hope we will end up with a solution which does not need any additions to the current function signatures. After all, our interfaces provide a similar complex functionality and they don't need any extra features within the function signatures either.

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.