Also, type arguments to generic function calls are *optional*: https://go2goplay.golang.org/p/w-q65tL5wh-
Therefore, when looking at a foo(bar)(baz), you have to know whether (bar) is a value or a type, which requires scanning the code to find the definition of 'bar' in this scope or nearest enclosing one. If bar is a value, then foo(bar)(baz) could be a generic function call (with inferred type) *and* one which returns a lambda, at the same time. I suspect this isn't likely to occur much in practice. There is an existing case which doesn't seem to bother many people: foo.Bar() Is this calling function Bar in package foo, or method Bar on variable foo? Go could have used different syntax for these cases, e.g. foo::Bar() for the package function call, but chose not to. Sometimes I come across this - when looking at someone else's code, it's not always instantly obvious whether "settings" is a package or a variable. Normally you don't need to look far though. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/95006cac-0acb-42da-a308-5be684336b90o%40googlegroups.com.
