[weberc2]

Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can’t tell if it’s a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.

[enneff]

You can tell if it’s a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

[shhsshs]

    a := Bar(baz)(buzz)

Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what “baz” is to be able to tell.

[agrajag]

Yeah, it's ambiguous, but be realistic: how often are you calling a function with a function return just to invoke that directly?

You usually won't see much of either sinice the type argument is only necessary when it can't be inferred.

[imtringued]

In Haskell this happens every time you call a function with two or more arguments.

[helper]

Normally you wouldn't write that since the compiler will be able to infer the baz type based on buzz (assuming this is a call to a generic function).

[weberc2]

That's a fair point, but there are still times when being explicit is useful or even required, and it doesn't hurt to use syntax that disambiguates easily.

[weberc2]

Reverse(x)(y)

Is that a function that returns a function or a generic Reverse function specialized over type x, invoked with argument y?

[enneff]

When a function returns a function, you rarely just call it immediately in Go. But even if that were common (and maybe it would become common with generics? I'd have to think that through) it is uncommon to have a type name as unrecognizable as 'x'.

I've always been a big advocate for unambiguous, clear code, especially in Go, but I don't see a big potential for confusion here.

[weberc2]

I don’t want to overstate the problem; I think it is a bit less readable. While types are rarely so indescriptive as “x”, they are often still plenty indescriptive, and I don’t know why we should introduce a syntax that depends on the clarity of type names or the frequency of other potentially ambiguous constructs when we could use a syntax that is unambiguous with no caveats and friendlier/more familiar to the larger body of programmers who have not yet tried Go.

[saturn_vk]

Some helpful syntax highlighting will probably help with these cases, I should think.