New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: removal of interface{} type in Go 2.0 #20188
Comments
Right now |
You delegate the formatting work to the individual types. Perhaps the above example with Let's define a Another advantage of this approach is that fmt can now work with user-defined types and custom formatting. |
Note that there is already a How would your proposal handle builtin types (int, float, ...) ? What about the |
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 Alternatively, we can follow what other languages have done by wrapping the primitive types. For instance, Java has 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 Go's interface is powerful, and "blank interface" type is currently undermining Go's interface from realizing its full potential. |
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. |
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." |
How do you propose to implement something like |
@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.
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. |
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. |
I'm not knowledgeable enough to add anything to this discussion but I wanted to say very interesting. Thanks guys! |
I don't think it is a good idea because empty interfaces can be very handy in situation like when you don't want to have any information of an object you are working with. For example, I am writing proxy-server, which sanitizes and redirects requests to real servers, which work with databases and return array of some objects (auth-tokens in my case) in reply. I really don't want my proxy-server to know anything about auth-tokens, their structure and have any dependency with realization of them, all I want is my proxy-server to expect an array of objects and pass it to caller. So using []interface{} seems to be pretty idiomatic. By this I put emphasis on structure of response (that it is an array), but really don't make any operations with its content, so I don't want to add type, concrete interface or any other restrictions to it. So as a result, I don't have any dependencies and additional information about types where I don't need them. |
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.
The text was updated successfully, but these errors were encountered: