>From an off-list response: 1. It only works if the function is defined in the same package as its >> used, or you'd need to use dot-imports. > > The dot-import in this case seems redundant because we have a variable > with which we try to use a method syntax and this variable has a specific > type and this type was defined in a specific package and all of this is > known at compile time. So can't the compiler just perform a check along the > lines of "if we use the method call syntax on this variable and if the type > of this variable is not an interface and if there's no method with the > required signature then check if there's a regular function with the > required signature defined in the same package as the type of the variable"? >
What you are describing here are effectively methods. You are just saying that, in addition to a method being declared as "func (T) M()`, it can also be declared as `func M(T)`. But nothing changes about the fundamental association between the body and the type, that characterizes a method. So it comes with exactly the same downsides as regular methods, with the added downside that we now have two different kinds of methods, that behave subtly differently (in that only one kind participates in interface implementation). It also means that a package can not define the generic `Map` method people seem to want on more than one type. Which, again, is unlikely to be what people want. I really encourage you to read #49085 <https://github.com/golang/go/issues/49085>, if you find the FAQ entry unsatisfactory. It contains a lot of additional discussion and in particular this suggestion and probably every variation of it you can think of has been discussed there already. -- 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 visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfESf3m_%3DWO0wvxecuYZXQLkjHSTZBdAF_sZWx2U2w7pbg%40mail.gmail.com.
