On Mon, Dec 19, 2022 at 12:25 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
>
>
> On Mon, Dec 19, 2022 at 8:31 PM Red Daly <redd...@gmail.com> wrote:
>
>> Methods cannot take type arguments, so I find myself writing `func Foo(o
>> Object) {...}` instead of `func (o Object) Foo()` in cases where Foo needs
>> a type parameter.
>>
>> I would like some type of pseudo-method in Go similar to Kotlin's
>> extension methods. Made up syntax:
>>
>> ```go
>> package foo
>>
>> func (o Object) #Foo[T any]() { /* ... */ } // Foo is a pseudo method of
>> Object
>>
>> func main() {
>> obj := Object{}
>> obj#Foo() // use # to differentiate from regular methods, or use .
>> }
>> ```
>> or something more clever.
>>
>> I expect a lot of the time people use methods for syntactic reasons, not
>> so those methods can be used to implement an interface. Methods appear in
>> godoc along with the type, get better tab completion than functions, etc.
>> I'm not proposing these pseudo-methods be used in any way to implement
>> interfaces.
>>
>> This may have already been discussed. There have been rejected proposals
>> for adding methods to types defined elsewhere (
>> https://github.com/golang/go/issues/37742 and
>> https://github.com/golang/go/issues/21401). However, I can't find a
>> proposal that proposes the Kotlin approach to "extension methods," which is
>> largely syntax sugar that allows `fun koo(k Kobject): void` to be called
>> like `k.koo()` by the programmer (rather than `koo(k)`) so long as `koo` is
>> statically resolved where such `k.koo` calls appear. Is there such a
>> proposal?
>>
>
> There are (at least) two:
> https://github.com/golang/go/issues/56283
> https://github.com/golang/go/issues/56242
> It's not *exactly* what you describe, but I believe it's close enough.
>
Thanks for the links. Note that while 56283 was declined citing lack of
emoji support
<https://github.com/golang/go/issues/56283#issuecomment-1283194040>, a
comment in issue 49085
<https://github.com/golang/go/issues/49085#issuecomment-948108705> has 35
thumbs up and no thumbs down for essentially the same proposal.
I suppose it makes sense to decide on this at the same time as deciding
whether/how to support type parameters for methods.
>
>
>>
>> This feature would be useful for defining these pseudo-methods on types
>> within a package or on types from other packages. Using a pseudo-receiver
>> type that's defined in another package raises some questions about how to
>> use the pseudo-method without surprising/confusing readers. Most
>> prominently for writing method-like generic functions.
>>
>> --
>> 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/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/e8685cd7-4691-4b74-8c9a-b4a8992dbd20n%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 on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2BjYSA__GwbLrUhhub47Bo2CT7txcVQ%3DryQC62J274WU4s%2B6Hg%40mail.gmail.com.
