feature request: Self type for self-referential interface definitions

[scwunch]

Usage of the Self type in an interface method, for example:

interface Clone {
  fn clone(self) -> Self
}

currently results in an error and a suggestion to use a type parameter instead. But having a real Self type seems like a much more natural fit in cases like Clone, and Equatable, etc.

[ivov]

This'd be a nicer notation, but it'd change what an interface means.

Lis interfaces are faithful to the Go model, where an interface is only a method set and types satisfy it implicitly. With Self the method set would become a template parameterized over the implementing type, which is a Rust trait concept grafted onto the Go interface model. This is a significant change that breaks the mental model for Go developers, making Lis interfaces into a hybrid that's harder to explain and understand.

I do like the benefit though, as Go's generic workaround e.g. type Cloner[T any] interface { Clone() T } is semantically inaccurate, plus Self expresses intent better and lowers redundancy. But the question is whether that is worth departing from the Go interface model.

[scwunch]

Oh, I had not realized that difference. My first thought in response to this was we could just add it as syntactic sugar. But then I realized that is not sound.

interface Add  // desugared to Add<Self>
	fn add(other: Self) -> Self

fn main() {
	let a: int = 5            // satisfies Add<int>
	let b: float = 3.4        // satisfies Add<float>
	let s: Slice<Add> = [a, b] 
	// Oops, the `Add` of `a` is not the `Add` of`b`!
	s.sum() 
	// adding ints and floats together
}

So yes, it would be quite a significant change, and likely would not help the goal of transpilation to "readable Go". Or Go interop.