proposal: removal of interface{} type in Go 2.0

[henryas]

Hi,

Given Go's powerful interface, I think it is possible to remove the "blank interface" type entirely, making the language simpler and more streamlined. For instance, instead of fmt.Printf(format string, args ...interface{}), we can perhaps write it as fmt.Printf(format string, args ...Stringer). The idea is to shift as much work as possible to the compiler and leave very little to the runtime type checking.

At the moment, the "blank interface" type is increasingly being misused as a convenient way to bypass Go compiler's type checking. There are places where "blank interface" is used in place where explicit interface could have been used.

The problem with runtime type checking is that you will never know if there is a problem until it is run. With static type checking, you can catch the bug during compile time. By removing the "blank interface" type, Go will have a stronger type system.

In addition, with explicit interface, it will be easier to understand what a type does than with "blank interface". There will also be less code associated with runtime type checking.

I know this will be a breaking change to the language as well as to the existing standard library, which is why I am proposing this for Go 2.x.

[ianlancetaylor]

Right now fmt.Printf can print any type, including types that don't implement the fmt.Stringer interface. How do you propose for that to work without an empty interface type?

[henryas]

You delegate the formatting work to the individual types. Perhaps the above example with Stringer is an oversimplification.

Let's define a Formatter interface that contains the following method: Format(fmt string) string. The argument fmt accepts precision modifier, etc. Then, implement the Formatter interface for each target type. The fmt is then defined as fmt.Printf(format string, args ...Formatter) and you don't need blank interface type anymore.

Another advantage of this approach is that fmt can now work with user-defined types and custom formatting.

[huguesb]

Note that there is already a Formatter interface: https://golang.org/pkg/fmt/#Formatter

How would your proposal handle builtin types (int, float, ...) ? What about the %p verb used to print pointers ?

[henryas]

It is merely a naming issue. The interface can be renamed to something else if you wish.

Currently, Go 1.x treats built-in types as special types. You can't attach any method on them. In my opinion, a type is a type. It would be better if we can treat built-in types just like any other types, and remove as much magic as possible from Go. Assuming we can attach methods to built-in types, we would implement the required interface for each built-in type, and they would be accessible to fmt. In fact, you can define them under the fmt package, so that they would be available only when fmt package is imported.

Alternatively, we can follow what other languages have done by wrapping the primitive types. For instance, Java has Integer class to wrap the int type. I don't think this approach is ideal. It seems like a convoluted way to merely attach behavior to primitive types. However, the option is there for consideration. In fact, you can already do this in Go 1.x.

As for %p, I don't currently have any answer to that. I am on a vacation and I am lazy to think about it. Removing "blank interface" type itself already breaks Go 1.x and its existing library, so quit trying to fit this into Go 1.x because it won't fit.

However, the benefit is clear. Removing the "blank interface" leads to a better design. For instance, in the fmt source code, you may notice it has many little functions to format each different type. Rather than hardcoding this in fmt, it would be better to move these functions into their respective types. As a result, fmt too is more flexible and extensible. Future support for more types can be done without changing the fmt codes. All this is intuitively accomplished just by removing the "blank interface" type from Go.

Go's interface is powerful, and "blank interface" type is currently undermining Go's interface from realizing its full potential.

[griesemer]

The "blank interface" as you call it falls out naturally from the definition of interfaces. Removing it from the language would require making the language more complex for no good reason. Forcing "good design" upon people by restricting the language this way is not going to be successful. If somebody wants to have a "minimal" interface, they will still use that minimal interface, even if that means it needs to have at least one method. Having the blank interface in Go enables Go to reach its full potential - not the other way around.

Needless to say that I am against this proposal.

[henryas]

The good design aspect is just the side effect of having an explicit interface. The primary objective -as stated in the original post- is to shift as much as possible to static type checking rather than relying on dynamic type checking. The second objective is to streamline the language and remove extra features that are non-essentials.

Anyhow, I just think it is wrong for a function to say "I'll take anything." or "I'll return anything."

[huguesb]

Anyhow, I just think it is wrong for a function to say "I'll take anything." or "I'll return anything."

How do you propose to implement something like atomic.Value then? One option would be generics but a lot of ink has already been spilled on that topic with no satisfactory conclusion so if you assume that as a pre-requisite it's much less likely that this specific proposal will be accepted.

[griesemer]

@henryas It's never been Go's primary objective to statically type checking everything. In general, there's programs that cannot be statically type-checked, no matter the type system. There's many meaningful programs we want to express where we want to use dynamic type checking. It makes not much sense to introduce an artificial restriction that doesn't solve any specific problem and will be circumvented as necessary anyway. Finally, you're not streamlining the language, you're adding complexity.

Anyhow, I just think it is wrong for a function to say "I'll take anything." or "I'll return anything."

This sounds very much like your personal belief/ideology - which you're of course entitled to - but it is not a convincing argument for others.

[henryas]

Sorry for the late reply. I have given it a good thought and let it sink for a bit during these couple of days, and I think you guys are right. There are use cases where blank interface type is irreplaceable in Go.

I have been learning Haskell and I am impressed with its type system. Haskell is able to figure out all the types during compile time, and I thought I could bring some of that to Go. I guess it's not possible. The key difference, as Huguesb pointed out, is that Go doesn't have generics. In the absence of generics, blank interface type becomes necessary.

This discussion has given me a new insight how the different components in Go work. Thanks!

I will let this thread linger for a bit in case if anyone has anything to add, but feel free to close it.

[happilymarrieddad]

I'm not knowledgeable enough to add anything to this discussion but I wanted to say very interesting. Thanks guys!