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 { ... }
})

zigo101 · 2024-03-20T17:33:49Z

@adonovan honestly, I don't very get your last reply.

Maybe I over-worried about it. Is it possible that the implementation struct type is a distinct zero-size struct (with an incomparable zero-size field) and the functions list is maintained outside of the struct values?

ChrisHines · 2024-03-20T17:41:18Z

@griesemer I like your construction, but why it is important for "each interface literal has its own user-inaccessible type"? What does that add over having each interface type used in a literal have its own type?

I ask because when hand writing mocks/fakes that use this pattern today I usually only make one type per interface I am mocking/faking. Obviously that saves me effort that the compiler doesn't care about as much, but does making each literal generate a new type have a specific advantage?

Merovius · 2024-03-20T18:01:25Z

@griesemer I would weakly argue in favor of requiring every method to be provided - if nothing else, then on the grounds that it is the more conservative choice and we can always relax it later, if we want to, but not the other way around.

Also, personally I would be in favor to have interface-literals just always be non-comparable.

Merovius · 2024-03-20T18:06:59Z

@go101 There is no need to have func-valued fields.

func F() (*string, error) {
    x := new(string)
    return x, error{func() string { return *x }}
}

(for example) could be de-sugared into

type _tmp struct {
    p *string
}

func (v *_tmp) Error() string {
    return *v.p
}

func F() (*string, error) {
    x := new(string)
    return x, &_tmp{x}
}

But also, I don't think this is a super important argument. If it can be implemented efficiently, great. If it can't be implemented efficiently, then there isn't a way for the user to do so either (it's not like the user can write code the compiler couldn't generate), so that wouldn't be counted against this proposal. It's a red herring.

griesemer · 2024-03-20T18:07:36Z

@ChrisHines This may not be a sufficiently convincing answer, but in the model translation, if there's exactly one struct type per interface type, comparison of interface literal values behaves differently. For instance, given an interface I:

I{} == I{} is false with the proposed model where each literal has its own dynamic type (playground)
I{} == I{} panics if the literals share the same dynamic type (playground) because now the literal values have the same type and can be compared, but the struct fields are incomparable.

Yet if I is actually any, then any{} == any{} is true (playground).

It seems a bit odd that comparing interface literals is ok if they are different interface types and the result is always false, but panics if they are the same interface type, unless the type is any in which case the result is always true.

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.

zigo101 · 2024-03-20T18:16:32Z

@griesemer

Is it a good idea to make I{} == I{} always panic by combining @adonovan and @ChrisHines's idea?

Merovius · 2024-03-20T18:25:17Z

The comparison only panics if both have the same type. It is allowed to compare uncomparable values of different types.

Requiring them to always panic comes with one theoretical complexity, which is that two interface literals from different packages would have to have the same type. I kind of get why that might be harder.

griesemer · 2024-03-20T18:30:45Z

@Merovius I just note that with other literals we are not required to provide all elements. So the proposal matches existing "behavior". I don't have a stronger argument than that, and this may not be strong enough. And yes, we wouldn't be able to tighten the rules after the fact, while with your suggestion we would.

With respect to comparisons, if we panic when comparing interface literals, it seems that this leads to odd behavior in some cases. For instance, I{} == I{} where I is not the empty interface would panic. But any{} == any{} wouldn't panic with the proposed implementation (and probably would require some additional machinery to make it panic). Also, if we compare interface literals against other interface values (not created from literals) we would not panic (playground and playground).

It seems simpler to always have a new inaccessible dynamic type for each interface literal. Then they can always be compared and the result is always false.

zephyrtronium · 2024-03-20T18:37:19Z

Without the different type per literal rule, there is also a question of identity: is fmt.Stringer{f} == interface { String() string }{f}? What about interface { String() string }{c.F} from two different packages?

I think a similar question applies given x := any{} => x == x, though. When we say "for each literal I{...}" there is a new type, is that lexical or per evaluation? I.e., given func g() any { return any{} }, is g() == g() allowed to be true?

griesemer · 2024-03-20T18:41:01Z

@zephyrtronium Indeed. Consider multiple interface literals created in a loop (playground). So even with different types per literal, this probably has to be lexical. Which leaves some odd behavior after all, either way.

zigo101 · 2024-03-20T18:41:23Z

@griesemer

... and probably would require some additional machinery to make it panic

Yes, @adonovan provided a machinery: #25860 (comment)

Also, if we compare interface literals against other interface values (not created from literals) we would not panic

But what the problem is it? It looks normal to me.

BTW, I have no strong opinions on the implementation details. I mean, any design is okay.

@zephyrtronium

is fmt.Stringer{f} == interface { String() string }{f}?

I prefer true. But I have not a strong opinion on this. I mean false is also okay, and panicking is okay, too. ;)

What about interface { String() string }{c.F} from two different packages?

In my opinion, all of the dummy struct types should be declared in the universal space.

zephyrtronium · 2024-03-20T18:43:05Z

I'm also a bit unclear on what "with a type name D that is inaccessible to the user" means. I assume "inaccessible" here means "unable to be referred to," along the lines of an unexported name in an imported package. But what is the result of reflect.TypeOf(any{}).String()?

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.)

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

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

zigo101 commented Mar 20, 2024 • edited Loading

ChrisHines commented Mar 20, 2024

Merovius commented Mar 20, 2024

Merovius commented Mar 20, 2024

griesemer commented Mar 20, 2024

zigo101 commented Mar 20, 2024

Merovius commented Mar 20, 2024

griesemer commented Mar 20, 2024

zephyrtronium commented Mar 20, 2024

griesemer commented Mar 20, 2024

zigo101 commented Mar 20, 2024 • edited Loading

zephyrtronium commented Mar 20, 2024

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

DeedleFake commented Aug 2, 2021 •

edited

Loading

DeedleFake commented Aug 2, 2021 •

edited

Loading

zigo101 commented Mar 20, 2024 •

edited

Loading

zigo101 commented Mar 20, 2024 •

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