The chained syntax does not contain a package name. There are three possibilities 1. It only works if the function is defined in the same package as its used, or you'd need to use dot-imports. Neither is likely to be acceptable. 2. There would be an ambiguity, if multiple imported packages define a `Map` function with the same signature. Definitely unacceptable. 3. You'd need to modify the syntax, to include a package-qualifier. That's possible, but the result seems like a mess that is even harder to read than chaining syntax in general and I don't think it is what people who have strong opinions in favour of the chaining syntax would like either.
This suggestion (and many variations trying to address this short fall) have come up in #49085 <https://github.com/golang/go/issues/49085> as well. You can read the details there yourself. My personal summary is "this is not going to happen". On Tue, 29 Oct 2024 at 05:04, Mark Mavzon <markush...@gmail.com> wrote: > As we all know Go doesn't have generic methods. The FAQ > <https://go.dev/doc/faq#generic_methods> states: > * "We do not anticipate that Go will ever add generic methods".* > Also the FAQ lists 4 options out of which the last one seems reasonable: > * Define that generic methods cannot be used to satisfy interfaces at all.* > But for some unknown reason it is considered a "bad design"*.* > And so I was thinkinking that maybe the regular functions can be adapted > for the usage as methods? Consider this: > type Maybe[A any] { > value any > } > func Just[A any](value A) Maybe[A] { return Maybe[A]{value} } > func Map[A, B any](_m Maybe[A], f func(A) B) Maybe[B] { > if _m.value == nil { > return Maybe[B](_m) > } > value := f(_m.value.(A)) > return Maybe[B]{value} > } > And then the usage: > maybeInt := Just(123) > maybeInt.Map(func(i int) { return fmt.Printf("%v", i) }).Map(...).Map(...) > > Can this break anything? What are the chances of such a proposal to be > approved by the Go Team? Specifically I propose that if a regular function > is defined with the first parameter name starting with the underscore we > should be able to use method call syntax with this function. And at the > same time this function should not take part in interface satisfaction in > any way. And if there's a method with the same signature this method should > be prioritized. > So what do you think? > > -- > 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/8ac5ee09-a68f-40b2-b311-94808304fd6en%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/8ac5ee09-a68f-40b2-b311-94808304fd6en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfHTsuK_d_k8kLp-xAbSxz--JWeFJCV%2B2gPN9nFS6fT5NQ%40mail.gmail.com.
