Language idea: Improved support for method-like functions

237 views
Skip to first unread message

Red Daly

unread,
Dec 19, 2022, 2:31:47 PM12/19/22
to golang-nuts
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?

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.

Axel Wagner

unread,
Dec 19, 2022, 3:26:17 PM12/19/22
to Red Daly, golang-nuts
On Mon, Dec 19, 2022 at 8:31 PM Red Daly <red...@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:
It's not *exactly* what you describe, but I believe it's close enough.
 

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...@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.

Red Daly

unread,
Dec 20, 2022, 12:05:24 PM12/20/22
to Axel Wagner, golang-nuts
On Mon, Dec 19, 2022 at 12:25 PM Axel Wagner <axel.wa...@googlemail.com> wrote:


On Mon, Dec 19, 2022 at 8:31 PM Red Daly <red...@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:
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, a comment in issue 49085 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.

Axel Wagner

unread,
Dec 20, 2022, 6:55:47 PM12/20/22
to Red Daly, golang-nuts
On Tue, Dec 20, 2022 at 6:05 PM Red Daly <red...@gmail.com> wrote:
Thanks for the links. Note that while 56283 was declined citing lack of emoji support, a comment in issue 49085 has 35 thumbs up and no thumbs down for essentially the same proposal.

I don't think the two are the same proposal. They have overlap, but they differ significantly. For example, the comment you link suggests that they should still be *methods* and thus inherently namespaced differently, while UFCS is about making *functions* callable using method syntax.
Both come with their own unique set of disadvantages and IMO UFCS has a significantly worse tradeoff.

That being said, we don't know how to implement parameterized methods either, so the point seems moot.
Reply all
Reply to author
Forward
0 new messages