Hello, > 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?
It could also be a call of a function within the struct value foo. foo.Bar(baz) can have at least four meanings: 1. calling a function Bar in package foo with parameter baz 2. calling a method Bar on value foo with parameter baz 3. calling a function Bar in struct value foo with parameter baz 4. converting a variable (or constant) baz to type Bar in package foo and with generics 5. instanciating a generic type Bar in package foo with type parameter baz > 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. Those ambiguities have always been there. To read foreign code, you have to look up the symbols from left to right. Most editors can help you with this. That said, I am fine with the current generics proposal. Regards, Harald -- 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/20200617174731.GA10193%40hweidner.de.
