I'm unclear on how you would use adapter[T]I. A value of T would be assignable to it and it would satisfy I? What happens when you call a method on an adapter that is not wrapping a T? Can you/how do you get the T back out of the adapter?

Oh yeah, I did leave that part out. Given a value t of type T, you can write (adapter[T]I)(t) to get a value of type adapter[T]I, and of course that value implements I and is therefore assignable to I. You can go back with an explicit conversion to T, which given a value i of type I looks like T(i.(adapter[T]I)).

This does seem to address the problem of wrapping known methods. How would type assertions work on a value instantiated from an adapter type? Can it uncover methods that are implemented by the underlying concrete type?

If some form of generics were added to Go2, wouldn't they likely solve this issue? Or rather, perhaps this problem should be kept in mind for a future generics design or proposal.

I admit I have not thought too much about it but I think that, if interface literal types make it into Go2 (issue #25860), this may be done without changing the language.

If we had interface literals, I would expect to be able to create interface values with some reflect function that takes a list of functions. We can already get the method set for a type, again using the reflect package. An hypothetical reflect.Adapter function would take a value of some type and an interface type, would create the wrappers, and would call the corresponding function to generate the interface value.

I am not totally sure this would be possible. It also has the drawback that you lose the information about the underlying type, although maybe an additional method may be used for that.

@yiyus That seems not connected to having interface literals though. It just requires being able to add methods or interface values in reflect and there is already an issue about that: #16522

IMO, I would much rather have real co-/contravariance for func and interface. I recognize the implementation difficulty of that though (mainly in regards to reflection and type assertions). This proposal seems still too unergonomic to be super useful, to be honest.

@mvdan I don't see how to do this using generics, unless by generics you mean some kind of generalized compile-time code-generation mechanism. The problem is that you need to construct an adapter type A that has all the methods of some interface type I, but without having to actually write those methods for A. If you have to write the methods, you haven't gained anything over just writing out the new type yourself. And I don't see how generics helps you discover the methods.

@ianlancetaylor you're right - I hadn't thought about this well enough. It still seems to me like this is worth considering together with generics for Go2, though. Particularly since we don't yet know how generics would fit into the language.

A related problem† is a type that would satisfy an interface if one or more of its operations were named differently.

† exacerbated by introducing generics that can use operators without either operator overloading or type classes (not that I think either of those are a good match for Go)

Say there is a generic Ordered interface with methods

Equal(T) bool
Less(T) bool

A value of time.Time almost satisfies Ordered(time.Time). It has an Equal method and it has a Before method which is Less in all but name. If the adapter concept were extended with renaming an adapter could be written something like

type Otime adapter[time.Time]Ordered(time.Time) {
  Before => Less
  // Equal is implicit as it already matches
}

Likewise, an int has all the correct operations but none of the correct names. If operators were allowed in the renaming it could look something like

type Oint adapter[int]Ordered(int) {
  == => Equal
  < => Less
}

(With the reverse direction, Equal => ==, explicitly disallowed).

Of course, an explicit wrapper type would provide the same function without a great deal of effort.

I don't see how to do this using generics

You can solve it on the caller side using the contracts in the current draft, but that doesn't help with the common interface per se: it moves the abstraction from run-time to compile-time.

interface StringValued {
	Val() string
}

contract StringValueFetcher(x T) {
	var _ StringValued = x.Fetch()
}

func FetchValue(type Fetcher StringValueFetcher)(x Fetcher) string {
	return x.Fetch().Val()
}

The problem is that you need to construct an adapter type A that has all the methods of some interface type I, but without having to actually write those methods for A.

That seems very similar to a more general problem: defining wrappers that pass through additional methods (examples: #16474, #21904, #27617; experience report here).

Since this problem and that one seem closely related, it would be nice if the solution could generalize to both. (It is not obvious to me whether this proposal does.)

This is an interesting problem space but this mechanism is too complicated. We aren't going to accept this proposal.