There is a workaround for this problem within the existing type system. To have a clonable interface C

type C interface {
   CloneC() C
   // other methods can be included as usual
}

you just make the method for cloning have a name specific to C.

Then, to implement with a concrete struct S, you can have

func (s *S) Clone() *S {
   // ... copy stuff and return it
}

func (s *S) CloneC() C {
   return s.Clone()
}

It is not as succinct as self but it avoids all the associated problems in the type system.

In my experience, real uses of self in a type system end up getting much more complicated than the simple examples used to motivate the usage.

In my experience, real uses of self in a type system end up getting much more complicated than the simple examples used to motivate the usage.

It's noteworthy that many other type systems are much more complicated than Go's; when you have things like covariance then the self type can become complicated.

There is a workaround for this problem within the existing type system. To have a clonable interface C...

What you have provided isn't a terrible solution to the issue. It still suffers from designing your structs around the interface, though, rather than designing the interface around a pattern. For instance, I wouldn't be able to describe a recurring pattern in a foreign package.

I'm not clear on whether this can be implemented. Presumably Foo is assignable to Cloner if Foo has a method Clone() Foo. A value of type Cloner has a method Clone() Cloner; that is, when calling the Clone method of a Cloner, you get a Cloner back. So something somewhere must be converting the Foo returned by Foo's Clone method to a value of type Cloner. That can't be at the call site, since at the call site we don't know the dynamic type of the Cloner. So it must be at the point where Foo is converted to Cloner; we must write a wrapper function that we store in the Cloner method table. But then we have to ask what should happen if we first convert Foo to a interface{} type, and then (in some other package) we convert that interface{} to Cloner. That conversion must succeed, but we have no place to write the wrapper function. The package where the conversion occurs knows nothing about Foo.

It's also worth noting that self is an unusual name in that it can only appear as the result type of a method in an interface type. I don't think we can permit self as an argument type, and I don't think we can permit a result type of *self or []self or func(self) self or interface { M() self }.

That conversion must succeed, but we have no place to write the wrapper function. The package where the conversion occurs knows nothing about Foo.

I'm not sure what you mean here. The package where the conversion occurs has access to the type descriptor for Foo, and can at least figure out the concrete return type of its Clone method: presumably with that information it can construct a function that can wrap that type as a Cloner interface.

(I suspect we could even write such a function using the reflect package today, except that we don't have a way to instantiate the Cloner interface itself — that's #4146.)

@bcmills That is true, it may be possible to construct the function using reflect.MakeFunc. But that is a very high overhead approach for what appears to be a simple interface conversion. And the calls to the method will be surprisingly slow.

So basically you want to replace interface name in parameter type as "self" word.

Does the current solution not suit your needs? Why such complication?

This will affect changes in existing editors, libraries etc. Also "self" word is so "pythonish". Let's go more in C/C++ direction than Python.

No, it's not the interface name

Look at the Cloner interface that I have provided, it matches func (T) Clone() T rather than func (T) Clone() Cloner. There is no way to represent this in current Go, and I have illustrated the problems with the generics "solution" to this.

Even though this issue is quite old, as I also often need this feature, and since we have the generic approach now, here are my two cents.

I played around with generics, but unfortunately they also don't seem to solve this particular problem. You can have generic Nodes and Edges, like described in the proposal, but they don't help you with the issue described here. If you want to return the interface itself, then you need to be aware of the interface.

Duck Typing would be much more complete when having something like the self keyword. This of course could also be combined with the generic approach. We already have the any keyword. We could have a self keyword that can only be used for generics and describe that T is referencing to itself:

type Cloner[C self] interface{
    Clone() C
}

Another example of where this would be helpful:

type LogFieldBuilder[C self, L Logger] interface {
  WithString(key, value string) C
  WithInt(key string, value int) C
  Build() L
}

This would enable us to finally have a type-safe structured-log that we can use when writing libraries.

Can't LogFieldBuilder be done without referencing the underlying type?

type LogFieldBuilder[L Logger] interface {
  WithString(key, value string) LogFieldBuilder[L]
  WithInt(key string, value int) LogFieldBuilder[L]
  Build() L
}

Yeah, it'll return the interface, but the returned interface will still provide the same methods and the Build() method will return L regardless of how many chained With*() methods it's called after.

Can't LogFieldBuilder be done without referencing the underlying type?

type LogFieldBuilder[L Logger] interface {
  WithString(key, value string) LogFieldBuilder[L]
  WithInt(key string, value int) LogFieldBuilder[L]
  Build() L
}

Yeah, it'll return the interface, but the returned interface will still provide the same methods and the Build() method will return L regardless of how many chained With*() methods it's called after.

Unfortunately, when returning the interface, the implementation needs to be aware of the interface:

package log 

import "github.com/some/lib"

type Logger[L any] struct {
}

func (l *Logger[L]) WithString(key, value string) lib.LogFieldBuilder[L] {
   l.addString(key, value)
   return l
}

So now the logger would need to be aware of lib in order to implement the interface and these two would become tightly coupled. If the logger could just return itself, then the logger wouldn't need to be aware of the lib and the lib wouldn't need to be aware of the logger. Then whoever needs logging in the lib can just plug in any logger that implements the interface ( arguably a library shouldn't log much, but sometimes when handling internal processes, a debug log is still very helpful )

Additionally, when only having a self-argument in the generic argument list, it could be considered that we can always infer that, to prevent a bit of the "Generic Poisoning" ( mentioned by @deanveloper )

A late update: The requested self-referential function signature inside the interface works well with type parameters in the current dev branch:

Playground

type Cloner[C any] interface {
	Clone() C
}

type Cloneable int

func (c Cloneable) Clone() Cloneable {
	return c
}

func CloneAll[T Cloner[T]](originals []T) (clones []T) {
	for _, c := range originals {
		clones = append(clones, c.Clone())
	}
	return clones
}

func main() {
	origs := []Cloneable{1, 2, 3, 4}
	fmt.Println(CloneAll(origs))
}

Note how the CloneAll function is parametrized with T Cloner[T]] to express that the parameter type T must be a type that implements the Cloner interface with itself (T) as the return type of Clone().

You are right @christophberger . It's not very easy to read but it is awesome that it works!

@mier85 - I confess I have unconsciously increased the reading difficulty by choosing slice parameters (which means additional square brackets). I am working on a better example for a blog article, even though you beat me already at that! :)

Edit: for reference, here is my article: How to use generics for creating self-referring interfaces

A personal experience that may shed some photons on the matter:

So I ran into this problem head-first during this weekend. I couldn't solve it without introducing some serious generic heavy-duty-machinery on the user's side since I had built a hierarchical generic interface (if that's what you call it?). In the end I ended up ditching the generic approach on the interface methods and generifying the algorithm's implementation. You can find a monologue at golangbridge.

I ran into this problem, when I tried to call an "overwritten" method, of a type with an embedded type.

package main

import "log"

type MyInterface interface {
	GetType() string
	SetSomething(s interface{}) MyInterface
}

type A struct{}

func (a *A) GetType() string {
	return "A!"
}

func (a *A) SetSomething(s interface{}) MyInterface {
	// sets something here...
	return a
}

// Type B has type A embedded:

type B struct {
	A
}

func (b *B) GetType() string {
	return "B!"
}

func main() {
	a := new(A)
	log.Printf("type: %s", a.GetType()) // Prints "A!"

	b := new(B)
	b.SetSomething("something")
	log.Printf("type: %s", b.GetType()) // Prints "B!"

	b2 := new(B).SetSomething("something")
	log.Printf("type: %s", b2.GetType()) // Prints "A!" because b2 is of type "MyInterface"
}

https://go.dev/play/p/2l_5OsLgzYM

@TAR5

when I tried to call an "overwritten" method

It's not what you did, not really. You called the GetType() of an A underlying a MyInterface that you confusingly named b2. There is no SetSomething() on B, and SetSomething() of A has a very explicit return a, which is what you got in b2.

The closest you can get to the fluent interface you seemed to be going for would be augmenting B with something like

func (b *B) SetSomething(s interface{}) MyInterface {
	b.A.SetSomething(s)
	return b
}

You have to keep in mind that Go does not have inheritance. The problems you are used to solving using inheritance in other languages you can't solve this way in Go.

@antichris

Thank you, now I understand that even if SetSomething had the return type self, a call to SetSomething on B only forwards it to the embedded type A, which would still return A.

@TAR5, it's not even forwarding: when you call a method that is not defined on an embedding type, your call just falls through to the method on the embedded value, which is completely oblivious of anything but itself. But, yeah, you got the gist of it.

This proposal is about being able to satisfy an interface by returning the concrete (not interface) value. So that, for your example, you could have

func (a *A) SetSomething(v interface{}) A { /* ... */ }
func (b *B) SetSomething(v interface{}) B { /* ... */ }

satisfying

type MyInterface interface {
	SetSomething(v interface{}) <magic>
}

where <magic> is a keyword that allows the concrete type implementing MyInterface that the method is defined on.

https://medium.com/@mier85/self-referencing-interfaces-in-golang-1-18-bcd6b5701992 Is this what you're looking for?

edit: didn't realize it's already poested here.

I believe I am having a comparable problem here where I need the interface to specify methods that can return values of the same type as they are called on. I don't see how it can be done given the current spec.

@Zyl9393 That is worth discussion, but not on this issue. As the Stack Overflow answer shows, there are ways to do what you want, even if they are less convenient than you desire.

I don't think there is anything to do on this issue now that we have generics and generic interface types. So I'm going to close this. Please comment if you disagree.

Mail group discussion regarding gonum's mat.Matrix type. With the self proposal the mat package does not have to be imported into every module that wants to implement the Matrix interface. This saves modules implementing the common mat.Matrix interface a rather large dependency.

type Matrix[T self] interface {
        At(i, j int) float64
        Dims() (r, c int)
        T() T
}

Sorry for bother everyone, I find another use case, when I try to import FromIter from rust to go.
I can't write the return type as the following without introduce self type:

type FromIter[T any] interface {
    FromIter(iter Iter[T]) ???
}

The return type are those who implement FromIter, not a specific type.

Hi @leaxoy ,

A closed GitHub issue is perhaps not the best location to discuss a programming problem. I would suggest that you move your question over to a discussion group like the Go Forum or the Golang-Nuts mailing list.

You will get many more eyes on your issue in either of these places.

To move forward quickly, start there by providing the following information:

How is Iter defined?
What part of your code errors out?
What error do you get?

And maybe you can even provide an example of the exact problem in the Go Playground. I already tried to figure out what the problem is, but I seem not to have recreated your exact scenario.

See you in the Go Forum or in the Golang-Nuts mailing list!