proposal: spec: interface literals #25860

smasher164 · 2018-06-13T06:14:06Z

Filing this for completeness sake, since it was mentioned in #21670 that this proposal had been discussed privately prior to Go 1. Just like literals allow the construction of slice, struct, and map values, I propose "interface literals" which specifically construct values that satisfy an interface. The syntax would mirror that of struct literals, where field names would correspond to method names. The original idea is proposed by @Sajmani in #21670 (comment).

Conceptually, this proposal would transform the following initializer

f := func(p int) { /* implementation */ }
x := interface{
	Name(p int)
}{f}

to the following type declaration and struct initializer

type _impl_Name_int struct {
	f func(p int)
}
func(v _impl_Name_int) Name(p int) { v.f(p) }
// … in some other scope
f := func(p int) { /* implementation */ }
var x interface{
	Name(p int)
} = _impl_Name_int{f}

As an extension to what’s mentioned in #21670, I propose that fields be addressable by both method names and field names, like in this example:

type ReadWriteSeekCloser interface {
	ReadWriteSeeker
	Closer
}

f := os.Open("file")
calls := 0
return ReadWriteSeekCloser{
	ReadWriteSeeker: f,
	Close: func() error {
		if calls < 1 {
			return f.Close()
		}
		return nil
	},
}

The default value for a method is nil. Calling a nil method will cause a panic. As a corollary, the interface can be made smaller to be any subset of the original declaration. The value can no longer be converted back to satisfy the original interface. See the following modified example (from @neild in #21670 (comment)):

type io interface {
  Read(p []byte) (n int, err error)
  ReadAt(p []byte, off int64) (n int, err error)
  WriteTo(w io.Writer) (n int64, err error)
}
// 3 method -> 2^3 = 8 subsets
func fn() io.Reader {
	return io{
		Read: strings.NewReader(“”),
	}
}

The nil values for ReadAt and WriteTo make it so the “downcasted” io.Reader can no longer be recast to an io. This provides a clean way to promote known methods, with the side effect that the struct transformation described above won't be a valid implementation of this proposal, since casting does not work this way when calling a nil function pointer through a struct.

Although this proposal brings parity between struct and interface initialization and provides easy promotion of known methods, I don’t think this feature would dramatically improve the way Go programs are written.

We may see more usage of closures like in this sorting example (now obviated because of sort.Slice):

arr := []int{1,2,3,4,5}
sort.Sort(sort.Interface{
	Len: func() int { return len(arr) },
	Swap: func(i, j int) {
		temp := arr[i]
		arr[i] = arr[j]
		arr[j] = temp
	},
	Less: func(i, j int) bool { return arr[i] < arr[j] },
})

Promotion of known methods also avoids a lot of boilerplate, although I’m not sure that it is a common enough use case to warrant a language feature.
For instance, if I wanted to wrap an io.Reader, but also let through implementations of io.ReaderAt, io.WriterTo, and io.Seeker, I would need seven different wrapper types, each of which embeds these types:

type wrapper1 struct {
	io.Reader
	io.ReaderAt
}
type wrapper2 struct {
	io.Reader
	io.WriterTo
}
type wrapper3 struct {
	io.Reader
	io.Seeker
}
type wrapper4 struct {
	io.Reader
	io.ReaderAt
	io.WriterTo
}
type wrapper5 struct {
	io.Reader
	io.ReaderAt
	io.Seeker
}
type wrapper6 struct {
	io.Reader
	io.WriterTo
	io.Seeker
}
type wrapper7 struct {
	io.Reader
	io.ReaderAt
	io.WriterTo
	io.Seeker
}

Here is the relevant change to the grammar (under the composite literal section of the spec):

LiteralType = StructType | InterfaceType | ArrayType | "[" "..." "]" ElementType | 
              SliceType | MapType | TypeName .

The text was updated successfully, but these errors were encountered:

themeeman · 2018-07-27T20:20:43Z

How would this work in terms of reflection? What would be the result of calling reflect.ValueOf on one of these interface literals? This would create the case that isn't currently possible where an interface isn't actually "wrapping" some underlying value. There is also the question of how they would work with a switch t.(type) statement.

smasher164 · 2018-07-28T18:06:07Z

I assume you mean to ask that if
i is an interface literal as described above
iv := reflect.ValueOf(i)
u := iv.Interface()
uv := reflect.ValueOf(u)
What would be the kind of uv? Also what operations on uv are valid?

You are right in that there isn't an underlying value being wrapped. That being said, since type switches can already switch on interfaces, doing so on an interface literal would simply not satisfy cases that check for concrete types.

b := []byte("some randomly accessible string")
pos := 0
rs := io.ReadSeeker{
	Read: func(p []byte) (n int, err error) {
		/* implementation */
	}
	Seek: func(offset int64, whence int) (int64, error) {
		/* implementation */
	}
}
r := io.Reader(rs)
switch r.(type) {
case *bytes.Buffer:
	// does not satisfy
case io.ReadWriteCloser:
	// does not satisfy
case io.ReadSeeker:
	// does satisfy
}

As to the representation of a literal's reflected value, if the same reflect package is used for Go 2, the underlying value can be a MethodSet. This does not have to correspond to its runtime representation, but this is a simple abstraction for the reflect package.

A MethodSet is just an interface that references all methods in the underlying value. Operations on a MethodSet are nearly identical to operations on an Interface. From the above example, if uv.Kind() is a MethodSet, then uv.Interface() is no longer a valid operation.

ut := uv.Type() will return a type with all of the underlying methods. Similar to an interface type, ut.Method and ut.MethodByName will return Methods whose signatures do not have a receiver and whose Func fields are nil.

smasher164 · 2019-11-06T01:48:59Z

I think the primary problem with this proposal is that it allows nil methods, which panic when invoked.

This violates a fundamental property of interfaces, where a type that implements an interface definitively implements a contract that its users can expect. Now a user of an interface cannot assume that a method is invocable, and the meaning of the interface lost.
The runtime would have to guard against an invocation of a method. I could see this slowing down invocations to all interface methods.
What is the difference, if any, between an interface that is nil, and an interface literal whose methods are all nil?

On the other hand, nil interfaces are extremely common, even though one could argue that they are also a violation of the contract described above, since users expect to be able to invoke its methods.

Additionally, I think allowing nil methods to prevent a downcasted interface from type-asserting into the original interface sounds nice since it allows the promotion of known methods. However, this behavior only exists because nil methods are allowed, and allows the runtime to convert an "unsafe" (non-invocable) interface to a "safe" (invocable) interface. This behavior implies that non-invocable interfaces shouldn't exist in the first place, and is too subtle and surprising.

The only alternative I can think of is to make a nil method provide some default no-op implementation of a method. Although this is safer than the previously mentioned, it seems just as subtle and surprising, but less powerful.

Ultimately, it appears impossible to require that no field in an interface literal is nil, since a value that is assigned to it could be nil at run-time. The only way to guarantee no field is nil would be to restrict each field to be a function literal or top-level function. However, this pretty much loses all of the power of interface literals, since it is only a marginal improvement (LoC-wise) over a type which is defined to implement an interface.

carnott-snap · 2020-03-12T01:27:50Z

Can this be added to #33892 for review?

smasher164 · 2020-03-12T02:18:37Z

/cc @golang/proposal-review

ianlancetaylor · 2020-03-12T19:47:45Z

This was reviewed and marked as NeedsInvestigation. At some point we'll re-review these issues.

beoran · 2021-08-01T09:27:17Z

I came here from #47487 which might be seen as competing with this issue.

Seeing that the interface literals proposed here have a serious problem with nil safety, as @smasher164 admits here: #25860 (comment) and considering that nil problems are a significant problem when developing software (look up "Null References: The Billion Dollar Mistake"), I strongly believe that any changes to the Go language should make it more nil safe and not less so.

Therefore I respectfully oppose this proposal, unless a way can be found to avoid the nil problem. #47487 on the other hand does not seem to have this nil problem, so I support that as an alternative.

Merovius · 2021-08-01T09:43:38Z

@smasher164

This violates a fundamental property of interfaces, where a type that implements an interface definitively implements a contract that its users can expect. Now a user of an interface cannot assume that a method is invocable, and the meaning of the interface lost.

This is not necessarily true. For example:

package main

type T struct{}

func (*T) Foo() {}

func (T) Bar() {}

type FooBarer interface {
	Foo()
	Bar()
}

func main() {
	var x FooBarer = (*T)(nil)
	// Does not panic
	x.Foo()
	// Panics - a nil *T is dereferenced when calling a method with value receiver.
	x.Bar()
}

I included two methods here, to demonstrate that this isn't simply "calling a method on a nil-pointer might panic, if that method dereferences it". The panic here is caused on a language-level, very similar (if not equivalent) to what would happen if an interface-literal contains a nil method.

The runtime would have to guard against an invocation of a method. I could see this slowing down invocations to all interface methods.

This is also not a worry. The runtime does not do nil-checks in general - it just does a call of the function pointer which causes a hardware trap when it's nil, which is then translated into a SIGSEGV which is caught by the runtime. That is, panics on nil derefercning/calling are free at runtime, in the happy path.

What is the difference, if any, between an interface that is nil, and an interface literal whose methods are all nil?

I would argue it's similar, if not the same, as a pointer being stored in an interface, where all methods panic when called with a nil-pointer - it's a non-nil interface, which panics if called. This is, as shown above, already possible and well-defined without any real isues.

smasher164 · 2021-08-01T20:12:55Z

@Merovius Good point about the dereferencing when the method has a value receiver.

zephyrtronium · 2021-08-01T20:36:48Z

Under this proposal, given an interface literal with a nil method, is the result of the method expression selecting that method nil or non-nil? E.g., is the output of the following program true or false?

package main

func main() {
	println(interface{ M() }{}.M == nil)
}

If the output of this program is true, it becomes possible to program around omitted methods. Contrarily, if it's possible, then people will do it, and I worry the end result would be complaints that interfaces cause boilerplate.

smasher164 · 2021-08-01T23:16:05Z

If nil methods are allowed, the output of the above program would be true. I would not want people to have to program around omitted methods. A nil method should only exist to aid narrowing conversions to a different interface type. Panicking when invoking a nil method should be similar to the invoked method panicking in its body.

DeedleFake · 2021-08-02T04:54:42Z

@beoran

#47487 can actually be used to replicate the functionality of this proposal in some circumstances, though it's a lot clunkier:

v := []int{3, 2, 5}

type Lesser interface{ Less(i1, i2 int) bool }
type Swapper interface{ Swap(i1, i2 int) }
type Lenner interface{ Len() int }
sort.Sort(struct {
	Lesser
	Swapper
	Lenner
}{
	Lesser:  Lesser(func(i1, i2 int) bool { return v[i1] < v[i2] }),
	Swapper: Swapper(func(i1, i2 int) { v[i1], v[i2] = v[i2], v[i1] }),
	Lenner:  Lenner(func() int { return len(v) }),
})

This pattern also works currently, but it requires top-level types to do the single-method-interface-implemented-by-a-function wrapper manually because there's currently no way to declare methods on a type inside another function.

DeedleFake · 2021-08-02T05:00:19Z

Is there any particular reason that this proposal can't be modified to require exhaustive implementation? I see a lot of arguments for and against it being accepted with nil methods, but what if methods could just simply never be nil? With a struct, adding more fields is a non-breaking change provided that any struct literals of that type use field names as the new ones will just be zero values, but adding a method to an interface is already a breaking change under almost all circumstances.

What's the benefit of allowing methods to be nil in this proposal at all instead of just requiring that all of them be implemented in any interface literal? The original proposal mentions something about downcasting them to smaller interfaces and being unable to revert that due to the lack of the method implementation, but why not just implement the smaller interface in the first place, then?

smasher164 · 2021-08-02T05:56:08Z

@DeedleFake

Is there any particular reason that this proposal can't be modified to require exhaustive implementation?

Even if we wanted to disallow nil methods, it is unclear how we would enforce that statically. Take this program for example, where readerFunc's being nil is determined by some runtime condition.

var readerFunc func([]byte) (int, error)
if runtimeCondition {
    readerFunc = func(p []byte) (int, error) { /* implementation */ }
}
reader := io.Reader{
    Read: readerFunc,
}

We could conservatively restrict methods in interface literals to either be top-level functions or function literals, but these rules are arbitrary and hard to teach. Additionally, a lot of the power of interface literals comes from the ability to change the implementation of some method by changing the variable binding for some closure. If you're going to define all of the functions up-front anyways, why not just make them methods on some basic type definition?

why not just implement the smaller interface in the first place, then?

The reason is to allow the promotion of known methods. Consider the example that @neild provides here: #21670 (comment). Basically, you know that some library wants to type-assert on your value for specific functionality (like fs.FS for example). You want to wrap that interface with your own functionality, but still allow some methods implemented by its underlying type to surface up.

Normally, you would have to type-assert for all combinations of methods you care about, and return a concrete type that implements that combination of methods. So if you wanted to wrap an fs.FS to do some additional work on its Open operation, but you still wanted StatFS and ReadDirFS to surface through, you would end up creating four concrete types.

The question is if this is even a problem worth solving for interface literals. However, even if it wasn't, nil methods would still exist, just for the ability to dynamically set an interface's method.

Merovius · 2021-08-02T06:01:55Z

@DeedleFake

I see a lot of arguments for and against it being accepted with nil methods, but what if methods could just simply never be nil?

The same reasons I mention here.

DeedleFake · 2021-08-02T06:13:55Z

Ah, duh. I was mostly confused by the defaulting of unspecified methods to nil and somehow completely overlooked manually setting them to nil. I was thinking of Java's subclass literals which use a regular method definition syntax, rather than a field setting syntax. Something like

sort.Sort(sort.Interface{
  Less(i1, i2 int) bool { ... }
  Swap(i1, i2 int) { ... }
  Len() int { ... }
})

Maybe inverting the problem and making it anonymous type literals instead of interface literals would make more sense. I remember the reflect.MakeInterface() proposal running into a similar problem as they slowly realized that they weren't actually creating an interface, but were rather creating a new anonymous type with the right methods to satisfy an interface. Maybe it would help to approach this from the point of view creating an anonymous, data-less type with inline, closured methods, and then it can just satisfy whatever interfaces, the same as any other concrete type.

Edit: To clarify, I'm saying ditch the interface name completely and just define an inline method set, then let the type checker do the work:

// sort.Sort() already defines its argument as being sort.Interface,
// so the regular type checker can easily sort this out.
sort.Sort(type {
  Less(i1, i2 int) bool { ... }
  Swap(i1, i2 int) { ... }
  Len() int { ... }
})

Merovius · 2024-03-20T19:38:07Z

Also, does the "different type per interface-literal" imply that every interface-literal has to allocate a new rtype, so that reflect.Type(x) != reflect.Type(y)? And if so, would that be potentially be a memory leak? I remember that there was a well-known issue that types created with reflect could not be garbage collected.

neild · 2024-03-20T19:55:28Z

I fairly strongly think interface literals should be required to provide implementations of all methods.

It is true that with other literals we are not required to provide all elements. However, we do require implementations of an interface to implement all methods of the interface. We can argue consistency from either direction here.

Leaving consistency aside, a compile time error explaining that a method isn't implemented is substantially safer and more comprehensible than a run-time panic. A panic can occur at a point far distant from where the interface value was created. A compile error will immediately point at the source of the problem.

I also don't see much practical value to permitting implicit partial implementation of an interface. There may be some cases in tests where partial implementation is useful, but this doesn't seem common enough or useful enough to justify the reduction in comprehensibility and safety. If you need to partially implement an interface, you can do so explicitly: io.ReadCloser{Read: readFn, Close: nil}.

doggedOwl · 2024-03-20T20:07:22Z

@neild Partial implementations in tests is very common in my experience and literals would be especially helpful in that case where the ratio of types/method to implement is very close to 1. if it's always 1 yes we can use the #47487 but very often in tests I need to implement 2/3 methods of some extensive interfaces.
While it's true that large interfaces are not the best way to write go, sometimes it's neccessary.

adonovan · 2024-03-20T20:20:33Z

We should not require that a given interface type has a single (unnameable) struct type for its closure, as this precludes optimizations that eliminate the double indirections both in control (method calls) and data (accesses to free variables). I like @griesemer's desugaring as an example of a legal (if suboptimial) implementation.

In other words, the identity of reflect.TypeOf(I{...}) should be implementation-defined.

griesemer · 2024-03-22T16:12:38Z

@Merovius By "different type per interface-literal" I meant a different type per lexical interface literal - this is bounded by the size of the source and statically know.

Merovius · 2024-03-22T16:17:34Z

@griesemer I think I'm confused, then by

If each interface literal has its own dynamic type, comparing interface literals is always ok and the result is always false. This seems easier to understand. It may also be simpler to implement.

ISTM that if we are talking "one type per lexical interface literal", with the model translation, this code would panic:

type J interface{ M() }
func F() J {
    return J{func() {}}
}
func main() {
    x, y := F(), F()
    x == y // panics: interface value have same, non-comparable type
}

Merovius · 2024-03-22T16:24:21Z

I think I'd be most inclined to support just specifying "interface literals are always comparable and compare as false", i.e. have them behave like float NaNs. That doesn't cleanly map to the model-translation, but ISTM it gives the easiest to predict behavior without having to fix ourselves to implementation details.

griesemer · 2024-03-22T16:28:18Z

The source-to-source transformation I proposed earlier can actually be adjusted easily to address some of the shortcomings that have been found so far: instead of using a dummy struct, we use a pointer to a dummy struct (playground).

Using a pointer in the interface variable (which an implementation would do anyway via boxing) addresses the comparison problems: two interface literals are equal only if they are in fact the same literal. Comparing an interface literal with any other interface will return false.

This leaves still open the following questions:

Should an interface literal be required to provide functions for all methods?
What is the dynamic type name of an interface literal as seen by reflection?

For 1) we just have to make a decision. The conservative approach is to require that all methods are present. This would be different from precedent for other composite literals.

For 2) I think the type name should be some artificial (compiler-created) name that makes it clear that these are special types. It may include the address of the actual type. The actual type may be marked such that it cannot be used via reflection (maybe?).

griesemer · 2024-03-22T16:30:45Z

@Merovius I think my previous comment addresses most of your concerns.

adonovan · 2024-03-22T17:18:14Z

https://go.dev/cl/573795 defines an analyzer to find types that are candidates for interface literals.

Here are 25 random results from the module mirror corpus.

~~I'll update the note with the complete statistics when the job finishes.~~

Update: the job identified a whopping 100,277 one-off types in 6456 modules (from a total corpus of around 20K modules) That's an average of 16 in those modules, which seems almost implausibly high, though the ones I looked at by hand seemed plausible.

I was tempted to adjust the analyzer to reject candidates which have more methods than the interface type (such as a one-off io.Reader that also has a String method), but that would falsely reject one-off types with helper methods that might be more neatly expressed as local closures; also, one could easily locally define a broader interface such as ReaderStringer and use a literal of that type. Perhaps the analyzer should put a bound on the total number of lines of the one-off type's methods?

A file containing the first 10,000 is attached.

This file https://go-mod-viewer.appspot.com/github.com/greenpau/[email protected]/pkg/acl/rule.go is the largest (apparently) non-generated example, with over 480 one-off types. Interface literals would save about 7000 lines of code in that file alone. There are dozens of files with over with 100 one-offs.

gopherbot · 2024-03-22T17:18:44Z

Change https://go.dev/cl/573795 mentions this issue: go/analysis/passes/oneoff: find "one-off" interface types

adonovan · 2024-03-22T18:59:22Z

One possibility to permit partial implementations without compromising on the "fail open" principle would be to use an ellipsis to affirm that the interface demands more methods than are provided. A call to any of them would panic.

rw = io.ReadWriter{
   Read: readFromStdin,
   ...
}

Of course, it's a change to the syntax of composite literals, which would make everything much more costly.

adonovan · 2024-04-30T18:16:20Z

I re-ran the analyzer across the corpus, this time modified to report only one-off types that satisfy an interface of no more than 3 methods, and whose methods together take no more than 20 lines of code.

Here are 100 findings selected at random from the first 30,000 to come out of the pipeline, which represents about 30% of the main module mirror corpus:

rsc · 2024-05-08T19:41:37Z

I'm just not seeing compelling use cases here yet.

I clicked on a handful at random and all of them look better to me with an explicit type. You need very trivial functions for this to be a win. After that I think the benefit of having a real type name and therefore a real method name in debuggers and debug prints becomes far more important than saving a few lines.

https://go-mod-viewer.appspot.com/github.com/aacfactory/[email protected]/barriers/barrier.go#L42
https://go-mod-viewer.appspot.com/github.com/jhump/[email protected]/desc/sourceinfo/wrappers.go#L35
https://go-mod-viewer.appspot.com/github.com/tetratelabs/[email protected]/internal/sysfs/adapter_test.go#L178
https://go-mod-viewer.appspot.com/github.com/pulumi/pulumi-aws/sdk/[email protected]/go/aws/quicksight/pulumiTypes.go#L8435
https://go-mod-viewer.appspot.com/github.com/fastly/go-fastly/[email protected]/fastly/newrelic.go#L67 (this should use slices.SortStableFunc anyway)
https://go-mod-viewer.appspot.com/go.skia.org/[email protected]/go/autoroll/autoroll.go#L339 (another use for slices.SortStableFunc)
https://go-mod-viewer.appspot.com/github.com/waldiirawan/apm-agent-go/[email protected]/internal/apmcloudutil/provider_test.go#L57

The only defensible ones are the calls to sort.Sort but even there having to write three methods gets to the point where it's probably not a win to inline it. I've always found it much clearer to move that code to a separate place in the file and have the call site just say

sort.Sort(byBuilder(x))

That's less to skim at a glance when reading it than

sort.Sort(sort.Interface{
    Len: func() int { return len(x) }, 
    Swap: func(i, j int) { x[i], x[j] = x[j], x[i] },
    Less: func(i, j int) bool { return x[i].Builder < x[j].Builder },
})

Writing the literal seems to optimize for writing the code and not for reading it, and that's the wrong optimization.

And as I noted these should use slices.SortStableFunc or sort.Slice anyway, and then there's no interface at all anymore.

Any use of sort.Sort should be dropped from the analysis, since we already have a better API for sorting. (Making a language change to improve the use of an API we've already added a better replacement for isn't worth it.)

ianlancetaylor · 2025-03-05T22:42:08Z

This is an interesting and even elegant idea. But the actual uses are less compelling in practice, at least for the cases with multiple methods. The single method case is #47487.

The most likely use of this would have been to implement sort.Interface, but today that type has been largely replaced by slices.SortFunc.

It's not completely obvious what type should be stored in the interface. It would have to be created, and named, with methods, all of which could be accessed via the reflect package. This can be addressed, but it's a complexity.

There is a straightforward mechanism for implementing this by hand, using a struct with a field and corresponding method for each of the interface methods. Then the interface literal is simply a struct literal. This is clearly less convenient. If we adopt #47487 that would provide another relatively ugly way to achieve the same effect.

The combination of a lack of compelling cases and the fact that there are (admittedly ugly) workarounds means that this is not urgent. Putting on hold.

-- for @golang/proposal-review

paskozdilar · 2025-03-13T14:19:02Z

It's not completely obvious what type should be stored in the interface. It would have to be created, and named, with methods, all of which could be accessed via the reflect package. This can be addressed, but it's a complexity.

Similar things are already done for anonymous structs:

var v any = struct{ Foo string }{Foo: "Bar"}
                                             
typeOf := reflect.TypeOf(v)
name := typeOf.Name()
field := typeOf.Field(0)
fieldName := field.Name
fieldValue := reflect.ValueOf(v).Field(0)
                                             
fmt.Println("typeOf:", typeOf)
fmt.Println("name:", name)
fmt.Println("field:", field)
fmt.Println("fieldName:", fieldName)
fmt.Println("fieldValue:", fieldValue)
                                             
/*
 *  Output:
 *      typeOf: struct { Foo string }
 *      name:
 *      field: {Foo  string  0 [0] false}
 *      fieldName: Foo
 *      fieldValue: Bar
 */

The only difference being that anonymous structs cannot have methods.
If we make interface literals behave like anonymous structs, but with methods, could we avoid naming altogether, and just use anonymous structure name?

var v any = io.ReadCloser{
	Read: func(p []byte) (n int, err error) {
		return 0, nil
	},
	Close: func() error {
		return nil
	},
}
                                                                                                                   
typeOf := reflect.TypeOf(v)
name := typeOf.Name()
method0 := typeOf.Method(0)
method0Name := method.Name
method1 := typeOf.Method(1)
method1Name := method.Name
                                                                                                                   
fmt.Println("typeOf:", typeOf)
fmt.Println("name:", name)
fmt.Println("method0:", method0)
fmt.Println("method0Name:", method0Name)
fmt.Println("method1:", method1)
fmt.Println("method1Name:", method1Name)
                                                                                                                   
/*
 *  Output:
 *      typeOf: struct {}
 *      name:
 *      method0: {Read  func(struct{}, []uint8) (int, error) <func(io.ReadCloser, []uint8) (int, error) Value> 0}
 *      method0Name: Read
 *      method1: {Close  func(struct{}) error <func(io.ReadCloser) error Value> 1}
 *      method0Name: Close
 */

One tricky thing that comes to mind is how should equality of reflect.Type of such anonymous-structs-with-methods be defined.
Previously, only named structures defined in package scope could have methods, and they had unique names.
With this approach, reflect.Types of all interface literals for a single interface would be equal, because they would have the same name, and same method names and types.

Personally, I'd prefer this approach over #47487, as it creates a special case for 1-method interfaces, and special cases are one thing Go has managed to more-or-less successfully avoid over the years.

Merovius · 2025-03-13T15:19:34Z

Similar things are already done for anonymous structs:
The only difference being that anonymous structs cannot have methods.

They can.

The real difference, is that the spec already contains the necessary syntax and semantics of a struct-literal. There currently is no such definition for interface literals. Non-nil interfaces need to have a dynamic type. We currently have no way to talk about what the dynamic type of such an interface literal would be.

Naively, it might seem we could use an anonymous struct, i.e. use struct{ io.Reader; io.Writer } for io.ReadWriter. But that doesn't work, mainly because the fields of such a struct can be modified, which should not be the case for interface literals. There are also implications of how type-literals behave, when defined in different packages and the fact that struct{ io.Writer; io.Reader } is different from struct{ io.Reader; io.Writer }, despite the corresponding interface types being equivalent.

So we probably would have to introduce a new class of type into the spec. None of this is insurmountable, but it requires sitting down and thinking through the phrasing.

paskozdilar · 2025-04-02T19:18:23Z

So we probably would have to introduce a new class of type into the spec.

My point was we don't have to invent a new type.
We can just say "interface literal expression creates an anonymous struct with methods that fulfill the interface, whose unexported fields are pointers to closured variables".

adonovan · 2025-04-02T20:05:03Z

So we probably would have to introduce a new class of type into the spec. None of this is insurmountable, but it requires sitting down and thinking through the phrasing.

My preference would be that each lexical instance of an interface literal creates a distinct struct type whose name and fields are implementation-defined; the fields would all be unexported. (It's not necessary to use anonymous fields in the implementation; anonymous fields are how you tell the compiler to generate delegation wrappers, but the compiler knows to do that in this case.) In other words, all you can rely on is type identity, and that it's a struct type.

Some might object that the spec and reflect package should be more prescriptive, but it doesn't seem fundamentally different to what you can already do using the reflect package:

func foo() {
   println(runtime.FuncForPC(reflect.ValueOf(foo).Pointer()).Name())) // "foo"
}

zephyrtronium · 2025-04-03T00:00:43Z

If the underlying reflect.Kind is UnsafePointer, then all representational questions are immediately answered as "opaque."

adonovan · 2025-04-03T02:12:18Z

If the underlying reflect.Kind is UnsafePointer, then all representational questions are immediately answered as "opaque."

The type has methods, so it must be a named type whose underlying type is not a pointer, which rules out unsafe.Pointer.

andig · 2025-04-03T07:16:45Z

Absolutely love this proposal. It would help us save tons of generated code for creating embedded structs like https://github.com/evcc-io/evcc/blob/master/meter/rct_decorators.go. We also notice considerable binary bloat from out current approach, not sure if implementation of this proposal would change this, too?

gopherbot added this to the Proposal milestone Jun 13, 2018

gopherbot added the Proposal label Jun 13, 2018

oiooj added the v2 An incompatible library change label Jun 13, 2018

gbbr changed the title ~~Proposal: Go 2 -- Interface Literals~~ Proposal: Go 2: Interface Literals Jun 13, 2018

gbbr changed the title ~~Proposal: Go 2: Interface Literals~~ proposal: Go 2: Interface Literals Jun 13, 2018

ianlancetaylor added the LanguageChange Suggested changes to the Go language label Jun 13, 2018

yiyus mentioned this issue Aug 2, 2018

proposal: Go 2: interface adapter types #26757

Closed

ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 25, 2018

ianlancetaylor changed the title ~~proposal: Go 2: Interface Literals~~ proposal: Go 2: interface literals Sep 25, 2018

bcmills mentioned this issue Nov 5, 2018

proposal: Go 2: allow packages to implement interfaces using .(package) syntax #28506

Closed

bcmills mentioned this issue Dec 5, 2018

proposal: spec: non-reference channel types #28366

Open

carnott-snap mentioned this issue Feb 5, 2020

proposal: Go 2: initialise funcs with custom type names #36855

Closed

ianlancetaylor mentioned this issue May 16, 2020

proposal: spec: generic programming facilities #15292

Closed

D1CED mentioned this issue Aug 1, 2021

proposal: spec: allow explicit conversion from function to 1-method interface #47487

Open

ianlancetaylor changed the title ~~proposal: Go 2: interface literals~~ proposal: spec: interface literals Aug 6, 2024

ianlancetaylor added LanguageChangeReview Discussed by language change review committee and removed v2 An incompatible library change NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 6, 2024

apparentlymart mentioned this issue Feb 5, 2025

proposal: spec: allow method declarations on function-local types #71562

Closed

ianlancetaylor added the Proposal-Hold label Mar 5, 2025

griesemer mentioned this issue Mar 5, 2025

spec: language change review meeting minutes #33892

Open

gabyhelp mentioned this issue Apr 14, 2025

proposal: spec: allow selective method embedding for interface definitions (like TypeScript's Pick) #73373

Closed

4 tasks

proposal: spec: interface literals #25860

proposal: spec: interface literals #25860

Comments

smasher164 commented Jun 13, 2018

themeeman commented Jul 27, 2018

smasher164 commented Jul 28, 2018

smasher164 commented Nov 6, 2019

carnott-snap commented Mar 12, 2020

smasher164 commented Mar 12, 2020

ianlancetaylor commented Mar 12, 2020

beoran commented Aug 1, 2021

Merovius commented Aug 1, 2021

smasher164 commented Aug 1, 2021

zephyrtronium commented Aug 1, 2021

smasher164 commented Aug 1, 2021

DeedleFake commented Aug 2, 2021

DeedleFake commented Aug 2, 2021 • edited Loading

smasher164 commented Aug 2, 2021

Merovius commented Aug 2, 2021

DeedleFake commented Aug 2, 2021 • edited Loading

Merovius commented Mar 20, 2024 • edited Loading

neild commented Mar 20, 2024

doggedOwl commented Mar 20, 2024 • edited Loading

adonovan commented Mar 20, 2024 • edited Loading

griesemer commented Mar 22, 2024

Merovius commented Mar 22, 2024

Merovius commented Mar 22, 2024

griesemer commented Mar 22, 2024

griesemer commented Mar 22, 2024

adonovan commented Mar 22, 2024 • edited Loading

gopherbot commented Mar 22, 2024

adonovan commented Mar 22, 2024 • edited Loading

adonovan commented Apr 30, 2024

rsc commented May 8, 2024

ianlancetaylor commented Mar 5, 2025

paskozdilar commented Mar 13, 2025 • edited Loading

Merovius commented Mar 13, 2025

paskozdilar commented Apr 2, 2025 • edited Loading

adonovan commented Apr 2, 2025

zephyrtronium commented Apr 3, 2025

adonovan commented Apr 3, 2025

andig commented Apr 3, 2025

DeedleFake commented Aug 2, 2021 •

edited

Loading

DeedleFake commented Aug 2, 2021 •

edited

Loading

Merovius commented Mar 20, 2024 •

edited

Loading

doggedOwl commented Mar 20, 2024 •

edited

Loading

adonovan commented Mar 20, 2024 •

edited

Loading

adonovan commented Mar 22, 2024 •

edited

Loading

adonovan commented Mar 22, 2024 •

edited

Loading

paskozdilar commented Mar 13, 2025 •

edited

Loading

paskozdilar commented Apr 2, 2025 •

edited

Loading