CC @griesemer

As you say, methods are syntactic sugar for functions, except that methods also satisfy interfaces. If we drop the possibility of satisfying interfaces, then it's not too obvious what we get from methods.

Mostly it seems to be useful for ergonomic reasons. For example, the classic functional iterator patterns are very clunky with top-level functions, but they work a bit better with methods:

// Top-level functions read backwards and visually separate logic in
// callbacks from calling the function, along with making it an
// absolute pain to modify the chain later, such as by inserting a
// map:
sum := iter.Reduce(
  iter.Filter(
    iter.Slice(someSlice),
    func(v int) bool { return v > 0 },
  ),
  0,
  func(sum, cur int) int { return sum + cur },
)

// Methods chain weirdly because of semicolon rules, but otherwise
// read much more cleanly and are far more editible:
sum := iter.Slice(someSlice).
  Filter(func(v int) bool { return v > 0 }).
  Reduce(0, func(sum, cur int) int { return sum + cur })

Personally, I think that it's worth it even without interface satisfaction, but I won't be too annoyed if the initial version of generics doesn't support them. I think it's worth keeping the discussion open, though, even after generics (hopefully) get put in. I also think that generic types should get inference the same as functions have if at all possible for similar reasons.

When using Go reflection to introspect the set of methods on a type with type-parameterized methods, what happens?

If interface satisfaction isn't allowed with generic methods, at least at first, then I think that it's probably not too surprising if they also can't be seen at all with reflect. It would have to be documented pretty clearly, though, I think. There may be a way that it could be done, but it would probably require pretty huge changes to reflect.

@thwd

type Getter[T any] interface {
        Get() T
}

type Zero struct {}

func (Zero) Get[T any]() ( _ T) {
          return 
}

In this example, would be Zero implementation of Getter[T]?

@tdakkota Excellent question.

In so far as visibility is concerned (as in the issue described in the current proposal), I believe this could work BUT it's more complex, because after specialization with e.g. T = int you get (using underscore as a mangle-character stand in):

type Getter_int interface {
    Get() int
}

type Zero struct {}

func(Zero) Get_int() (_ int) {
    return
}

At first glance, Get_int() int does not implement Get() int. I can't think of a straightforward and general way (n type-parameters in Getter and m possibly distinct type-parameters in Zero.Get) of translating this to Go1 via go2go. Maybe there is a way if we narrow it down.

Secondly, the constraints on T in Getter[T] would have to be identical than the constraints on S in Zero.Get[S]. That can be checked relatively straight-forwardly.

My opinion is that there might be a way, but it's complex enough that I would leave it out for now. Baby steps.

Putting this on hold pending any decision on incorporating generics into the language.

Putting this on hold pending any decision on incorporating generics into the language.

Could this be put on the table for 1.20?

Thanks for raising this issue. Although this issue is older, there is a lot more discussion on #49085, so closing this issue in favor of that one.