I think the convention here is a typed package-level variable assigned to the blank identifier:

var _ Foo = (*Baz)(nil)
var _ Bar = (*Baz)(nil)

If *Baz doesn't implement Foo or Bar, you'll get a compile-time error.

I think the convention here is a typed package-level variable assigned to the blank identifier:

var _ Foo = (*Baz)(nil)
var _ Bar = (*Baz)(nil)

If *Baz doesn't implement Foo or Bar, you'll get a compile-time error.

Thank, I did not know about this convention yet, seems like it will help. Seems like a workaround for a missing language feature though!

at times without helpful information about why the struct is incompatible with the interface.

What do you mean? It should say which function it caught that isn't implemented.

type Baz struct implements Foo, Bar { ... }

I have a few issues with this syntax:

1. You are giving a special syntax for struct definitions. Notice that for a struct it would be type T struct implements I { <struct definition body> } (implements declaration in the middle of the full type declaration), but for any type that doesn't have a "body", the declaration would be type T []string implements I (implements declaration after the full type declaration). For consistency we would want the implements declaration always after the full type declaration, but that would look bad in my opinion.
2. It does not allow for saying a pointer type should implement an interface
3. It encourages defining structs around interfaces, rather than defining interfaces around patterns

Also, we have a way to do this already:

type T struct {}

var _ io.Reader = T{} // T should implement io.Reader
var _ io.Reader = (*T)(nil) // *T should implement io.Reader

Despite working quite a lot with the language for about 6 weeks or so (like 200 hours!) I did not know about this convention var _ Foo = (*Baz)(nil). I'm half-way through Alan A. A. Donovan and Brian W. Kernighan's book, so maybe it's in there and I haven't gotten to it yet.

Perhaps then the proposal is to elevate this somewhat cryptic convention to a language feature.

Baz implements Foo
Baz implements Bar

Honestly the difference between pointer types and non-pointer types as it relates to interface implementations is one of the most confusing things I've encountered in the language thus far, so I can't really comment on that until I figure out how it works. There's ambiguity in my mind about what it means to be a pointer vs a non-pointer when I am an interface. And I haven't fully understood, when implementing an interface, what it means to have pointer vs. non-pointer receivers. I basically do one or the other and then go try combinations of & and * until it works. I'm mostly a C++ programmer, if that explains it.

In fact in the example:

type T struct {}

var _ io.Reader = T{} // T should implement io.Reader
var _ io.Reader = (*T)(nil) // *T should implement io.Reader

It is not currently clear to me why both of these would be necessary. It seems like one or the other would suffice. Is there some reading that would help me here?

In regards to 'encouraging defining structs around interfaces' that argument is a bit dogmatic for my taste. I guess there's some fear of Golang being used in way that looks too much like traditional OO?

I think that adding a new keyword to the language is a pretty heavyweight approach for an optional mechanism that can already be done in a different way.

I was unaware of the convention to assign a struct to an unnamed instance of the interface.

It is not currently clear to me why both of these would be necessary.

In terms of this, I meant more to show that you would do var _ io.Reader = T{} to assert T implements io.Reader, and var _ io.Reader = (*T)(nil) would be the equivalent for pointers

It is not currently clear to me why both of these would be necessary.

In terms of this, I meant more to show that you would do var _ io.Reader = T{} to assert T implements io.Reader, and var _ io.Reader = (*T)(nil) would be the equivalent for pointers

Yes, I see that only one or the other is possible depending on which type of receiver the implementation has. I still don't understand pointer/non-pointer receivers and the semantics of the interface usage, but thankfully the compiler does! 👍