proposal: spec: allow type parameters in methods

[mariomac]

According to the Type parameters proposal, it is not allowed to define type parameters in methods.

This limitation prevents to define functional-like stream processing primitives, e.g.:

func (si *stream[IN]) Map[OUT any](f func(IN) OUT) stream[OUT]

While I agree that these functional streams might be unefficient and Go is not designed to cover this kind of use cases, I would like to emphasize that Go adoption in stream processing pipelines (e.g. Kafka) is a fact. Allowing type parameters in methods would allow constructing DSLs that would greatly simplify some existing use cases.

Other potential use cases that would benefit from type paremeters in methods:

• DSLs for testing: Assert(actual).ToBe(expected)
• DSLs for mocking: On(obj.Sum).WithArgs(7, 8).ThenReturn(15)

---

Edited by @ianlancetaylor to add: for a summary of why this has not been approved, please see https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#no-parameterized-methods .

[fzipp]

The document also explains what the problems are. So what are your solutions to these?

[zigo101]

This proposal is good to define an io.ImmutableWriter {Write(data byteview)(int, error)} interface:
https://github.com/go101/go101/wiki/A-proposal-to-avoid-duplicating-underlying-bytes-when-using-strings-as-read-only-%5B%5Dbyte-arguments

[ianlancetaylor]

This proposal is a non-starter unless someone can explain how to implement it.

[deanveloper]

@ianlancetaylor from the generics proposal

Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function.

I think this solution makes the most sense. They could then (under the hood) be treated a regular function. The reason why this would be useful is that methods do not only serve the purpose of implementing interfaces; methods also serve as a means of organization for functions that operate on particular structures.

It may be a bit of a challenge about how type-parameterized methods would appear in "reflect", though.

[zigo101]

The problem would be simpler if the parameter type possibility set is known at compile time,

It may be a bit of a challenge about how type-parameterized methods would appear in "reflect", though.

One new problem I'm aware of is there might be many methods have the same name for a certain type.
So the Type.MethodByName might return a slice value (assume the parameter type possibility set is known at compile time).
Any other new problems?

[AndrewHarrisSPU]

One new problem I'm aware of is there might be many methods have the same name for a certain type.

If we're ultimately talking about multiple dispatch, the languages that really cater towards this do a massive amount of overloading. One language I find fun and interesting with this style is Julia, where things like + or * or show have hundreds of overloads when booting the REPL. From a software engineering perspective, there are tradeoffs - I absolutely trust Go to compile long into the future, and to have fewer surprises about packages ... Remarkably and IMHO related to robustness, Go doesn't have programmers defining function overloads in source code - I'm not convinced generics should change this.

Particularly for stream-to-stream conversion, I do think that the List Transform example is useful. We have to provide a concrete T1 -> T2 conversion function, but in a sense we have to figure out how to convert T1 to T2 in any kind of system.

I think it's also often possible to have a higher-order function that generates conversion functions, while more specialized conversion functions are also naturally expressible in Go. Example: a very generic color conversion API might specify an interface with ToRGB() and FromRGB() methods, and this can go pretty far. We can express 8-bit to 16-bit RGB conversion here through the interfaces, the same as e.g. HSV or LAB conversions, but there's a faster bit-shifting path. With a sense of a generic default, something like bufio.Scanner seems plausible - where the default just works, but we can optionally provide a better color conversion the same way we can provide a different SplitFunc.

[DeedleFake]

@deanveloper

Even just that would allow for, for example, an iterator implementation, though it does require wrapping it in another type because of the lack of extension functions:

type Nexter[T any] interface {
  Next() (T, bool)
}

type NextFunc[T any] func() (T, bool)

func (n NextFunc[T]) Next() (T, bool) {
  return n()
}

type Iter[T any, N Nexter[T]] struct {
  next N
}

func New[T any, N Nexter[T]](next) Iter[T, N] {
  return Iter[T, N]{next: next}
}

func (iter Iter[T, N]) Map[R any](f func(T) R) Iter[R, NextFunc[R]] {
  return New(NextFunc[R](func() (r R, ok bool) {
    v, ok := iter.next.Next()
    if !ok {
      return r, false
    }
    return f(v), true
  })
}

// And so on.

Usage is still awkward without a short-form function literal syntax, though, unfortunately:

s := someIter.Filter(func(v int) bool { return v > 0 }).Map(func(v int) string { return strconv.FormatInt(v, 10) }).Slice()
// vs.
s := someIter.Filter(func(v) -> v > 0).Map(func(v) -> strconv.FormatInt(v, 10)).Slice()

[batara666]

This will add so much complexity

[deanveloper]

@batara666 can you explain why? adding type parameters to methods doesn’t seem like it’d add that much complexity to me.

[Merovius]

I think before we can think about if and how to do this, we should first address the "no higher level abstraction" restriction of generics, i.e. the inability to pass around a generic type/function without instantiation. The reason is that if we allowed additional type parameters on methods, we'd also de-facto allow to pass around generic functions without instantiation:

type F struct{}

func (F) Call[T any] (v T) { /* … */ }

func main() {
    var f F // f is now de-facto an uninstantiated func[T any](T)
}

Therefore, to allow additional type-parameters on methods, we also have to answer how to pass around uninstantiated generic functions.

Moreover, if we'd allow passing around uninstantiated generic types/functions, we could already build the abstractions given as motivations in the proposal-text.

So, given that solving "no higher level abstraction" is a strictly easier problem to solve, while providing most of the benefit of solving "no additional type parameters on methods", it seems reasonable to block the latter on solving the former.

Lastly, I'd urge everyone to consider that these limitations where not left in the generics design by accident. If they where really that easy to solve, the solution would have been in the design to begin with. It will take some time to solve them.

[zigo101]

The "type" concept almost means a memory layout.
If we could use the 1.18 constraint concept as general types,
then many problems will be solved.

A value of a subset type could be passed/assigned to a superset type.
A function with a superset type parameter could be used as a function with a subset type parameter.

For Go, the change would be too large.
It is best to experiment the idea on a new language.

[AndrewHarrisSPU]

I was (far too) pleased (with myself) when I figured out this is possible: https://gotipplay.golang.org/p/1ixYAwxwVss

The part about lifting values into type system 'symbols' feels like a bit DIY and tricky, not sure there isn't something better here. I did feel like the dispatch() call is technically interesting. Inferring from the function/method supplied to dispatch() wasn't obvious to me at first. Without overloading methods, just different instantiations of the dispatch() function, it is plausible to arrive at the correct dispatch over a set of concrete implementations.

[ianlancetaylor]

I'm putting this proposal on hold until we have more familiarity with the current generics implementation.

[mariomac]

Playing with a new library that intensively uses generics, I provided an equivalence implementation between a Method and a Function:

https://github.com/mariomac/gostream/blob/bf84997953f02b94e28da0d6c4d38585d2677df2/stream/str_to_str.go#L5-L14

At the end, the difference is only where the parameter is placed (as a receiver, or as a first argument), but the function allows you map to a Stream of different type and with the method you can only generate streams of the same type.

With the code from the above link, I verified that this compiles:

type Mapper[IT, OT any] func(Stream[IT], func(IT)OT) Stream[OT]
var _ Mapper[int, float64] = Map[int, float64]

Simplifying, and obviating some internals from Go that I might ignore, I could see the generic Mapper type as a "single-method generic interface", that is implemented by the Map function, and it can be instantiated into a Mapper instance with concrete types.

In order to overcome the No parametrized methods issue pointed by @fzipp, from my partial view, I think that the example issue can be approached the same way as Java does: using interface{} behind the scenes and panic if the customer did a bad assignment (also the compiler could warn about the unsafe operation). Then for example the code from the example:

func CheckIdentity(v interface{}) {
	if vi, ok := v.(p2.HasIdentity); ok {
		if got := vi.Identity[int](0); got != 0 {
			panic(got)
		}
	}

Would be translated to something equivalent to:

func CheckIdentity(v interface{}) {
	if vi, ok := v.(p2.HasIdentity); ok {
		if got := vi.Identity(0).(int); got != 0 {
			panic(got)
		}
	}

Then the third line would panic if the v interface does not implement Identity[int]. The same way that Go does currently when you try to cast an identity{} reference to a wrong type.

In this case, we are translating the error check from the compile time to the runtime, but anyway this is what we actually have now if lack of parametrized methods forces us to continue using unsafe type castings.

[ianlancetaylor]

In your rewrite of CheckIdentity what do we gain by using a type parameter with the method? If the code is not type checked at compile time, we can just return an interface type, which already works today.

[deanveloper]

I think that the example issue can be approached the same way as Java does: using interface{} behind the scenes and panic if the customer did a bad assignment

This is a bad idea in my opinion - Type erasure is one of the most annoying limitations of generics in Java. I think it would go against the grain of the simplicity that Go aims for.

[mccolljr]

I don't really have a horse in this race, but I find this proposal interesting and wanted to put down my thoughts.

Based on what I see here: https://go.godbolt.org/z/1fz9s5W8x
This:

func (x *SomeType) Blah() { /* ... */ }

And this:

func Blah(x *SomeType) { /* ... */ }

compile to nearly identical code.

If we have a type S:

type S struct {
    /* ... */
}

...and S has a method DoThing with a type parameter T:

func (s S) DoThing[T any](arg T) { /* ... */ }

...then we effectively have a generic function with the signature:

func DoThing[T any](s S, arg  T) { /* ... */ }

Of course, if we have a generic type G:

type G[T any] struct {
    /* ... */
}

...and G has a method DoStuff with a type parameter U:

func (g G[T]) DoStuff[U any](arg U) { /* ... */ }

...then we effectively have a generic function with the signature:

func DoStuff[T, U any](g G[T], arg U) { /* ... */ }

In order to use either of these "functions", all of the type parameters have to be known.

That means that in the case of S, the only way to refer to S.DoThing is to instantiate it: S.DoThing[int], S.DoThing[float64], etc.
The same is true for G, with the additional requirement that G is also instantiated: G[int].DoThing[float64], etc.

Within this limited context, it seems to me like it wouldn't be a huge leap to allow type parameters on methods - it ends up referring to what is essentially a generic function, and we know things about generic functions:

1. They can't be used unless all type parameters are known statically at compile time, and
2. Each unique instantiation results in a unique function, semantically speaking (the actual implementation of course may choose to use a single function and internally use type switching, etc, etc)

The mechanism by which this interacts with interface definitions/implementations is less clear to me. Though, I think it is reasonable to say that a generic interface can't be implemented directly - it must be instantiated first. I'm not as sure of this, but it seems that it might also be true that an interface can only be implemented by a fully instantiated type.

Even in code like this:

type GenericInterface[T any] interface {
    Foo() T
}

type GenericStruct[T any] struct {
    Bar T
}

func (g GenericStruct[T]) Foo() T {
    return g.Bar
}

func MakeGeneric[U any]() GenericInterface[U] {
    return GenericStruct[U]{}
}

It seems like, within the context of MakeGeneric[T], we could consider both GenericInterface[T] and GenericStruct[T] to be instantiated with the some specific type T, which is the type value given to the type parameter U in MakeGeneric[U]. The determination that GenericStruct[T] implements GenericInterface[T] in this context is different from making a general statement that "GenericStruct[T] implements GenericInterface[T] for all T", which is what I would think of as "implementation without instantiation"

One area that seems complex is interfaces whose methods have type parameters.

For example, if we had:

type Mappable[T any] interface {
    Map[U any](func(T) U) []U
}

What would it mean to "instantiate" Mappable[T]?
Can you use a type assertion such as blah.(Mappable[int]?
If Mappable[T].Map had the signature Map[U comparable](func(T) U) []U, would a type with a method
Map[U any](func(T) U) []U be treated as implementing Mappable[T]?
This kind of interface seems to introduce a lot of ambiguity that would be difficult to resolve in a satisfactory manner.

It seems much simpler to disallow that kind of interface entirely, and just require something like:

type Mappable[T, U any] interface {
    Map(func(T) U) []U
}

I think that could still be just as useful, depending on how interface implementation is handled when the underlying type has methods with generic parameters.

As an example:

// Slice[T] provides slice operations over a slice of T values
type Slice[T any] []T

// Map[U] maps a Slice[T] to a Slice[U]
func (s Slice[T]) Map[U any](func (T) U) Slice[U]

type Mappable[T, U any] {
    Map(func (T) U) Slice[U]
}

// In order for this assignment to be valid:
// 1. Slice[int] must have a method named Map ✅
// 2. Slice[int].Map must have the same number of arguments ✅
// 3. Slice[int].Map must have the same number of returns ✅
// 4. Slice[int].Map must have the same types for each argument and return ???
var _ Mappable[int, float64] = Slice[int]{1,2,3}

It seems reasonable to me to say that Slice[int] implements Mappable[int, float64], since the method Map on Slice[int] can be instantiated & called with a U set to float64.

In this case, assuming that methods with type parameters are allowed, I would think the compiler could do something like:

1. Notice that Mappable[int, flloat64] is implemented for Slice[Int] when Slice[int].Map is insantiated with float64
2. Generate the code for that instantiation of Slice[int].Map, and
3. Use the pointer to that particular instantiation of Slice[int].Map in the vtable

If you're calling the method an the interface object, then you only have access to that one particular instantiation of
the Slice[int].Map method. If use a type assertion to get back the original Slice[int] type, then you can of course call any number of Map variants on it, because the compiler knows what the concrete type is again.

To summarize:

Given that it is a feature of go that interface implementation can be tested at runtime via type assertions, reflection, etc, I don't see any way around banning generic methods on interface definitions. However, because methods are more or less sugar for functions, it seems to me it would be possible to allow generic parameters on methods of concrete types, and to allow these methods to participate in implementation of fully instantiated interface types.

[Merovius]

Given that it is a feature of go that interface implementation can be tested at runtime via type assertions, reflection, etc, I don't see any way around banning generic methods on interface definitions. However, because methods are more or less sugar for functions, it seems to me it would be possible to allow generic parameters on methods of concrete types, and to allow these methods to participate in implementation of fully instantiated interface types.

I don't think you are solving the problems from the design doc, though:

type IntFooer interface { Foo() int }
type StringFooer interface { Foo() string }
type X struct{}
func (X) Foo[T any]() T { return *new(T) }

func main() {
    var x X
    x.(StringFooer) // How does this work? Note that we can't use runtime code generation
    reflect.ValueOf(x).MethodByName("Foo").Type() // What is this type?
}

This fulfills all your criteria, it uses no parameterized interfaces and X is a concrete (non-parameterized) type. In particular, answering these questions here is the minimum required to make this feature useful.

It is very easy to look at the proposal text and think "this would be a useful feature to have, I obviously would like it in the language". But because it's such an obvious feature to put in, it would be great if people ask themselves why the Go team didn't put it in in the first place. Because there are reasons and these reasons need answering.

[alvaroloes]

I would like to drop an idea here which I think can be useful for the "type parameters in methods" topic. Maybe it has an obvious flaw I haven't seen or it has already been considered or discussed, but I couldn't find anything about it. Please, let me know if so.

With the current proposal, we can't have type parameters in methods but, couldn't we achieve the same effect if we put the type parameters in the type definition?

I mean, instead of doing this:

type Slice[T any] []T

func (s Slice[T]) Map[U any](func (T) U) Slice[U]

Do this (move the U type parameter from the method "Map" to the struct):

type Slice[T any, U any] []T

func (s Slice[T,U]) Map(func (T) U) Slice[U]

@Merovius Wouldn't this solve the issue you mentioned in the above comment? Your example would end up like this:

type IntFooer interface { Foo() int }
type StringFooer interface { Foo() string }
type X[T any] struct{}
func (X) Foo() T { return *new(T) }

func main() {
    var x X[int] // You are forced to specify the type parameter here with the current proposal. I guess it could be inferred it this were an initialization instead of a declaration only
    x.(StringFooer) // This would fail, as it doesn't conform to the interface
    x.(IntFooer) // This would pass
    reflect.ValueOf(x).MethodByName("Foo").Type() // "Foo(X) int"
}

I think this would work with the current proposal without changes.

As I said, I could be missing something obvious here. Let me know if that's the case.

[Merovius]

@alvaroloes

couldn't we achieve the same effect if we put the type parameters in the type definition?

You can easily do this, but it's not the same effect. People who want this specifically want the type-parameter of the method to be independent of the type itself, to implement higher-level abstractions.

[alvaroloes]

I see, thanks. After thinking it twice, I now see that what I propose would be very limiting as, after instantiating the type, you could not call the method with different type parameters (for example, call "map" with a function that return strings one time and then another time with a function that return ints).

All right, I know there was something obvious here. Thanks for the response!

[mccolljr]

I don't think you are solving the problems from the design doc, though:

I'm sure that's true, I probably would benefit from reviewing it again. To be fair, though, I wasn't trying to put together a concrete proposal - I understand why this is a complex topic and why it isn't in the first pass at generics, and why it may never be added to the language. I don't have a horse in this race beyond the fact that I find this interesting. My intent was to think out loud about what restrictions might make this more concretely approachable. Also, for what it's worth, I think that disallowing parameterized methods on interface types could be seen to addresses some of the problems put forth in the proposal.

type IntFooer interface { Foo() int }
type StringFooer interface { Foo() string }
type X struct{}
func (X) Foo[T any]() T { return *new(T) }

func main() {
    var x X
    x.(StringFooer) // How does this work? Note that we can't use runtime code generation
    reflect.ValueOf(x).MethodByName("Foo").Type() // What is this type?
}

[...] answering these questions here is the minimum required to make this feature useful.

I do not disagree. I feel as if you may have misinterpreted my intent. I am not saying "this is so easy, look at how we can do it" - I am saying "here is an interesting constraint that might make this more approachable, and which could perhaps be used as the basis for additional discussion"

I'm willing to brainstorm this, but again I am not proposing a concrete solution as much as attempting to provide a possible set of constraints for discussion. If that exercise shows that thia feature would too complex, that is a totally acceptable outcome in my opinion.

Obviously we cannot use runtime code generation, I don't recall proposing that nor do I think it is necessitated by anything said above. Given that, here are some possible (not exhaustive or comprehensive) directions the compiler could choose:

For x.(StringFooer)

• The program could encode the types that a generic method/function/etc has been instantiated with. This would allow x.(StringFooer) to correctly select the implementation of Foo that applies. Of course, if X.Foo is never explicitly instantiated with string, then it could be surprising to a user that this fails. Perhaps the cost of that potential confusion is unacceptable. This failure could of course be solved by adding var _ StringFooer = X{} somewhere in the code, and perhaps the panic message could indicate that the failure was due to uninstantiated generic methods rather than uninstantiated

• The compiler could generate a fallback implementation using interface{} or some minimum interface that it can use in these situations. In the case of type sets, the fallback could use a type switch. Perhaps if type switching on ~ types is implemented this becomes easier.

For reflect

• Similar to above, the compiler could generate metadata about which instantiation were generated and this could be introspectable from reflect. A public IsGeneric flag could be added to the descriptor for methods and calls to method values could validate the given types against the instantiation list to verify the proper code had been generated.

• Similar to above, the compiler could simply generate fallback implementations for generic methods (functions etc).

It is very easy to look at the proposal text and think "this would be a useful feature to have, I obviously would like it in the language". But because it's such an obvious feature to put in, it would be great if people ask themselves why the Go team didn't put it in in the first place. Because there are reasons and these reasons need answering.

This is exactly what I attempted to do here. I wrote this at 1am on the last legs of a cup of coffee, and it seems I failed to consider some scenarios in my comment. A simple "How would this address X and Y" would have accomplished the same effect without this lecture at the end.

[Merovius]

To be clear, this is what the proposal says about this question:

We could instantiate it at link time, but in the general case that requires the linker to traverse the complete call graph of the program to determine the set of types that might be passed to CheckIdentity. And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable.

Or, we could instantiate it at run time. In general this means using some sort of JIT, or compiling the code to use some sort of reflection based approach. Either approach would be very complex to implement, and would be surprisingly slow at run time.

Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function.

So while parameterized methods seem clearly useful at first glance, we would have to decide what they mean and how to implement that.

The solution you suggest seem a variation on the second option here.

[qm3ster]

I have read the issue thread and I still don't understand why adding just the ability to implement generic methods on concrete types (allow generic funcs to specify a receiver) with absolutely no changes towards allowing interfaces to ask for such methods to be implemented, even at the syntax level, would block any further decision.

Is it about generic methods possibly fulfilling the requirement for a concrete method in an interface if the concrete method is a valid instantiation of the generic method?

interface I {
  Meth(string) string
}
type S struct {}
func (s *S) Meth[T any](v T) T {
    return v
}
var _ I = &S{} // <- is this the blocking question?

Because if in the future it starts fulfilling the requirement it would break resolution?

I am new to Go and would really appreciate if someone could elucidate.

[Merovius]

@qm3ster I'm not sure what you are basing the question on. Is there a specific comment that made that claim, that you didn't understand?

The FAQ says about this option:

4. Define that generic methods cannot be used to satisfy interfaces at all.

Interfaces are an essential part of programming in Go. Disallowing generic methods from satisfying interfaces is unacceptable from a design point of view.

This isn't about compatibility or keeping options open.

[qm3ster]

That line is exactly about keeping options open to me.
The "unacceptable" situation of disallowing generic methods from satisfying interfaces is the status quo, by nature of disallowing generic methods being declared in general.
What I am trying to determine for myself is whether the incremental step is impossible today because:
(1. Allowing declaring generic methods with no interaction with interface methods whatsoever)
-> (2. Will lead to code that declared some breaking in some resolution scenario I can't think of)
-> (3. Meaning they can never start fulfilling interfaces due to go backwards compatibility guarantees)
-> (4. Making the "unacceptable from a design point of view" situation permanent)

[Merovius]

The "unacceptable" situation of disallowing generic methods from satisfying interfaces is the status quo, by nature of disallowing generic methods being declared in general.

This is too literal an interpretation of the sentence. The solution declared unacceptable is adding generic methods while not having them participate in interface-satisfaction. Note that the premise of the section is that we add generic methods, that there are four options to treat their interaction with interfaces and that next sentence is

None of these choices are good ones, so we chose “none of the above.”

That is the status quo. What you describe is option 4.

[markusha]

Wanted to suggest a way to "implement" the generic methods for interfaces but it looks like jpap has already suggested something similar. Oh well. Here're my thoughts on the matter.

1. For an interface's generic methods disallow the use of "any" constraint for type parameters.

type HasIdentity interface {
    Identity[T int64 | float64](T) T // ok
//  Identifoo[T any](T) T // not allowed
}

This should prevent the compiler from using every type there is in the code for generating the required methods as it will be explained later.

2. For a concrete type's generic methods there should be no restrictions for constraints.

type Foo struct {}
func (foo Foo) Identity[T any](v T) T { return v } // ok

3. Generic methods that are invoked on variables of concrete types should behave just like regular generic functions.

foo := Foo{}
// the same as calling Identity[T any](foo Foo, v T) T with T = int
// and the same body as the method
v := foo.Identity(123)

4. Types' generic methods should only be able to satisfy interfaces' generic methods. Types' non-generic methods should only be able to satisfy interfaces' non-generic methods.
5. When the whole program code is analyzed by the compiler we should know exactly which types satisfy which interfaces and which types satisfy which constraints.

5a. Every generic method in every interface should be turned into several non-generic methods with their type parameters substituted for every possible concrete types according to their constraints. For the HasIdentity example above we'll have:

type HasIdentity interface {
    Identity[int64](int64) int64
    Identity[float64](float64) float64
}

5b. For every type that has generic methods and that satisfies some interface the corresponding constraints from the interfaces' generic method type parameters should be used to generate all possible method variations for this type. So for the Foo struct above we know that according to its generic Identity method's signature it should satisfy the interface HasIdentity so we take the corresponding type parameter constraint from HasIdentity's method (int64 | float64) and use it to generate the needed methods:

type Foo struct{}
func (foo Foo) Identity[int64](v int64) int64 { return v }
func (foo Foo) Identity[float64](v float64) float64 { return v }

So in the end we get the following:

var a any = Foo{}
// the HasIdentity's method table has 2 entries
// which map to the corresponding 2 entries in the Foo's method table
h := a.(HasIdentity)
i := h.Identity(123)
f := h.Identity(1.0)

Can't say much about the plugins for now. Considering all of their restrictions, the need to keep the zoo of toolchains and the fact that the plugin package essentially recommends not to use plugins does anyone use them at all?

[CannibalVox]

Sorry to throw a beehive into the conversation given how little I know about the particulars, but could this gordian knot not be severed by adding something like C#'s extension methods to go? https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods

Extension methods would have two issues:

• How do you decide which extension methods apply to which types across multiple packages?
• How do you prevent naming collisions?

However if all the feature is doing is improving generic ergonomics, the requirement that the extension methods live in the same package as the type it is extending and not create naming collisions can exist. You have the implementation benefits of free floating methods, and there are no issues with reflection, because the method is what it claims to be.

The main issue is that it would be a syntax level change to correct a minor ergonomic problem.

[DeedleFake]

@CannibalVox

That's been proposed in several different ways before, including something like an Elixir/OCaml-type pipe operator so that regular functions could be reordered from inside-out to left-to-right, but they were all shot down. See #33361 and #49085 (comment), for example.

[CannibalVox]

The suggestion related to extension operators was shot down due to go not knowing how to manage them cross package, but as I mentioned above, it can be law that they need to occupy the same package

[DeedleFake]

I think that's way too restrictive, though. Take the example of iterators. Does that mean that all methods that can be chained to an iter.Seq must be declared in the iter package? That would mean that any experimentation with them, like in the proposed x/exp/xiter package, or any third-party packages that add more features that aren't handled by the standard library would have to be called as top-level functions. Mixing and matching like that would probably be even worse than just writing all of them inside-out:

slices.Collect(xiter.Something(seq.Filter(...)).Map(...))

I think the best approach is a pipe operator. It completely avoids cross-package issues and would simply be a better way to write certain things. The biggest problem, ignoring disagreements over whether it should even be added or not in the first place, is parsing it with semicolon insertion. Because of how semicolon insertion works, unless it got some kind of special casing, it would have to be

seq |>
iter.Filter(...) |>
xiter.Something(...) |>
iter.Map(...) |>
slices.Collect()

instead of the much nicer

seq
|> iter.Filter(...)
|> xiter.Something(...)
|> iter.Map(...)
|> slices.Collect()

[CannibalVox]

Does that mean that all methods that can be chained to an iter.Seq must be declared in the iter package?

Yeah, just like it is now. The proposal is to allow type parameters in methods. The author of iter.Seq would then be allowed to have type parameters in their methods. Problem solved.

[perj]

@CannibalVox I'm sorry but I'm having a hard time understanding what new syntax you're proposing, it doesn't seem obvious from the link you provided.

[CannibalVox]

There would need to be a way for free functions to identify that they are "extension methods" for a particular type. In the link provided, C# does this by having static methods declare their first argument as this. That's not an option for golang.

In doing this, an extension method func ExtMethod(??syntax?? obj SomeType) would be callable on objects of type SomeType with someTypeObj.ExtMethod().

This would allow the method ExtMethod to remain a free method and appear as a free method in reflection and satisfy everone's expectations about what ExtMethod is and how it acts, except it can be called on an object of SomeType for ergonomic/organization purposes.

[ianlancetaylor]

@CannibalVox I think you are describing the ability to add a method to a type such that the method does not appear in an interface. That has been suggested many times in this issue, and we've consistently rejected it, because the point of methods is to satisfy interfaces. Apologies if I've misunderstood.

[jonathansharman]

@ianlancetaylor

the point of methods is to satisfy interfaces

I really hope we can reconsider that assumption. It ignores other practical reasons for defining methods on a type, including better API discoverability via code completion and method chaining, especially for builder types.

(In short, +1 to option 4 from the FAQ.)

[entonio]

@ianlancetaylor

the point of methods is to satisfy interfaces

I really hope we can reconsider that assumption. It ignores other practical reasons for defining methods on a type, including better API discoverability via code completion and method chaining, especially for builder types.

(In short, +1 to option 4 from the FAQ.)

I don't think the assumption can be challenged. Go does have a number of principles that have made its evolution slow, but on the other hand have succeeded in keeping the language small and coherent. Those are rare qualities and as such they should be preserved.

And, yes, after hundreds of messages discussing the possibilities, the problem with methods with generic parameters always comes back to satisfying interfaces and how it doesn't seem to be possible without mandating a specific implementation strategy, which in turn is an unacceptable requirement. That amounts to saying that it doesn't seem to be solvable.

The thing is... do the go designers think that it's unsolvable in principle, or just that a solution hasn't been found yet? If the former, I have nothing to add. But if the latter... wouldn't it be possible to waive the interface thing until a solution is found? I mean, rather than 'methods with generic parameters don't implement interfaces', 'methods with generic parameters don't implement interfaces for now'?

I understand that there could be conflict if a method with a generic parameters happens to coincide with an actual method from an interface, but that doesn't look intractable.

Can this be differentiated from a lax approach where everything goes and the consequences are worked out later? I don't know. If it can't, then ignore it.

[gophun]

do the go designers think that it's unsolvable in principle, or just that a solution hasn't been found yet?

The FAQ is quite clear: "We do not anticipate that Go will ever add generic methods."
https://go.dev/doc/faq#generic_methods

[CannibalVox]

@CannibalVox I think you are describing the ability to add a method to a type such that the method does not appear in an interface. That has been suggested many times in this issue, and we've consistently rejected it, because the point of methods is to satisfy interfaces. Apologies if I've misunderstood.

Well, they're technically functions.

[ianlancetaylor]

@entonio I do not think that we can do something temporarily, as once we permit methods that are ignored by interfaces, we can't suddenly change those methods to satisfy interfaces. That would be a surprising change that would surely break some programs.

[atdiar]

I don't see why these would be methods. (the risk is to make type checking undecidable)

On the other hand I can understand the appeal of scoped generic functions.
It's a difficult topic though.
For one, it's basically some sort of dependent type where a generic instantiation depends on an already instantiated value.

Beyond this, the true issue is chaining.
I could imagine it being a feature that would stand on its own.
One issue is the order for operator precedence.

var r SomeStruct
r.Value = f(a, b)..h(e)..(A.g)(c).Format()

(I prefer using double dots instead of a pipe operator. Also easier to write)

What is evaluated first in the above?

[DeedleFake]

I think the double dots are confusing if there are any single dots in the same pipeline. A completely different operator with space separation makes the ordering more obvious, too.

[atdiar]

@DeedleFake that could be a choice but regardless of the symbol used, the question about the choice of precedence still remains?

To be fair the question of precedence comes from knowing of the experience of the Dart's language designers (they have such an operator but it's not universally liked by the designers themselves).
That's why I am asking. They chose lowest precedence while I would naturally choose a precedence that is simply higher than the single dot. And add the necessary parentheses where required.

From a discussion we had:

It needs to be the lowest because a key design goal was to allow you to call a series of sets on the same target and = has very low precedence.

But they have specific semantics. (understand sets as chaining methods of a same receiver)
Their operator discards the results for instance and applies to the original receiver.
I think in our case we are thinking of passing return values as input arguments? Also using functional method transformation where it applies?
The latter being potentially confusing, it might require additional notation.
f(*p, *p) being equivalent to (*p) f(*p) could be brittle.

In a chain, we may want to be more explicit about which inputs of a function come from the chain.

i.e. f(g)..h(.., .., a) where the double dot notation also acts as a placeholder, enforcing the arity.
Notation is not important here. Just the concept.

Then there are other considerations that actually explain why Dart made the choice it made (chaining methods).
For us, even if we went a different route, it's not sure that a function return value will exactly match another function input argument list. (@ianlancetaylor already pointed that)

[fengzhi09]

there is another way out,if we can declare the interface or struct(implement) can be part .if the answer is ok ,then we can define help method much more easier.
// file collections/seq.go in repo A
package collections
part interface sep[T any] {T Next()}

// file collectionx/seq.go in other repo B(rely on A)
package collections
part interface sep[T any] {T[] Collect()}

in repo C(rely on A) seq means a simple interface with one method
in repo D(rely on B) means seq must have 2 methods
programers will be happy to build lib in modules better and better.

[jpap]

@entonio I do not think that we can do something temporarily, as once we permit methods that are ignored by interfaces, we can't suddenly change those methods to satisfy interfaces. That would be a surprising change that would surely break some programs.

@ianlancetaylor, we can use a pragma to exclude the method from implementing any interface. In the interim, decree any method having type parameters and lacking the pragma as a compile-time error (e.g. "syntax error: method having type parameters must be excluded from interface implementation"). Later, once an implementation strategy is agreed upon, package authors can freely remove their pragmas to participate in interface conversions and type assertions as the need arises.

I appreciate that nobody wants another pragma, but the above approach avoids surprises and future breaking changes. Being pragmatic about it, I'd rather have a small number of //go:no-interface-impl in my codebase and a lot of elegant chained generic method calls, than no pragmas with a lot of awkward boilerplate workarounds at each call site.

// Identity returns the argument.
// This method does not allow type S to implement any interfaces having the same signature.
//go:no-interface-impl
func (S) Identity[T any](v T) T { return v }

// Identity2 is similar to Identity, but triggers a compile-time error because it lacks the pragma.
func (S) Identity2[T any](v T) T { return v }

[dsnet]

Technically, the Go compiler already has support for the //go:nointerface pragma which hides a method from being able to implement an interface. However, this feature is only available if the fieldtrack experiment is enabled.

A certain large company uses go:nointerface along with fieldtrack as a means of significantly trimming down the compiled binary size. This is especially relevant with Go protobufs, which tends to generate a large number of accessor methods, which leads to binary bloat linking in every accessor method even if they are never called.

Given that there is utility to go:nointerface outside of generics, I wonder if it should be promoted to becoming a first-class feature of the Go language. If such a feature existed, then perhaps that's the answer to permitting type parameters in methods?

[DeedleFake]

@atdiar

I thought of the Dart operator when I saw your suggestion, but Dart's operator does something completely different. Dart calls it the cascade operator and it basically just calls a normal function, plus a few other things, but then returns the object instead of the method's return value. That way you can chain methods that weren't designed for it inside of a single expression, i.e.

final m = new Map<int, int>();
m
  ..[3] = 2
  ..putIfAbsent(3, () => 1)
  ..[5] = 1
  ;

A lot of languages, such as Elixir and Rust, also use the .. operator for ranges.

[atdiar]

@DeedleFake yes that's what I mentioned in the previous post (it's edited).