-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
spec: allow 'any' for 'interface{}' in non-constraint contexts #33232
Comments
I often use a type alias for this which isn't much extra work: type any = interface{} |
I agree with the sentiment that |
I support this proposal, though not strongly. In the early days of using Go, I often encountered the |
I support this proposal too. Its simple to implements and the readability becomes better |
I don't support this proposal. The power of Go is that for many things there's a single way of doing things. A language gets bloated easily once we start adding additional syntaxes only because some people prefer one over the other. People new to the language may initially learn the 'any' keyword, but then read existing code, and still have to look up the interface{} keyword. Effectively, the burden of learning the language increases, rather than decreases. |
Yes and on w/ what @Freeaqingme has said, we also must take care when creating different ways of doing the same thing because:
The examples are unimportant, but the point should be clear. If we choose to make this our |
Besides readability reason, less verbose and weird (esp. for new gophers) is another good point of this proposal. @Freeaqingme When a gopher later suddenly realizes that
This is not what a qualified tool should do.
Builtin identifiers are not keywords, users can shadow them as needed. |
If you really believe interface{} is so bad, I'd suggest you extend this proposal to deprecate interface{} and eventually remove it. I'm not a fan of that either, but my primary argument was against having two keywords for essentially the same thing. That argument would be moot if interface{} keyword is removed.
We still have 'whatever' and 'anythingReally' as alternatives 😋 |
Is there anyone cloud explain the historical reason of why interface{} is designed as interface{} rather than anything else? |
@Freeaqingme
|
It's not a special design, but a logical consequence of Go's type declaration syntax. You can use anonymous interfaces with more than zero methods:
Analogous to how you can use anonymous structs anywhere a type is expected:
An empty interface just happens to match all types because all types have at least zero methods. Removing interface{} would mean removing all interface functionality from the language if you want to stay consistent / don't want to introduce a special case. |
@fzipp good point. I realized that after posting my earlier comment as well. Then it makes zero sense to remove that. I'm sticking with my original reply; we can simply explain why interface{} is interface{} and how it works. There's then no need to add an additional keyword that basically is/does the same thing. |
There was a built in type alias working like type byte = uint8 in every Go package from the very early days. It is not me being this proposal supporter or the other way, just a well known fact. |
In Haskell when we write guards: abs n
| n < 0 = -n
| otherwise = n where otherwise = True Just imagine how much less readable it is if one uses It's only good if there's a single GOOD way of doing things. |
If we are able to add generics to the language, then I suspect there will be many fewer cases where people write |
The any value acts like the top type in a type system and it may be usefull sometimes even with generics. Say we have a higher order function that composes just for logs. You do not need a contract of anything like that for that type if you want to log the argument and then perform the action. Something like (take it as a pseudocode):
The top type would be good in this case instead of writing |
Also relevant: https://groups.google.com/g/golang-nuts/c/iAD0NBz3DYw |
In the latest generics design, we find the following:
I think the "It will not be valid to use any as anything other than a type constraint." is a bad idea. It is far more simple and consistent to allow the use of the any alias |
I feel very strongly that Having a confusing-to-beginners pattern of using Having The only thing we must not do is make it more confusing. Adding |
I disagree too. Maybe in Dart, Typescript, Rust, etc. it can be good improvement, otherwise in go, you can just put in package simple file like package something
type any = interface{}
type null = struct{} // for channels f.e.
// something that you want to syntax sugaring could be amazing practice! I mean, |
If I recall correctly there was a promise not to change the language in Go 1. And adding a new keyword is quite a big change. |
@makhov: This isn't adding a new keyword, but rather adding a new builtin alias. Any local declarations of |
Change https://golang.org/cl/351456 mentions this issue: |
@dsnet That's really good, thank you. But do you think it's a good idea to write something like this:
How many people will be involved to support the change that brings nothing? We need changes in our tools, libraries, and applications. |
Generally, it's not a good idea to shadow an identifier (builtin or otherwise), but it's not incorrect either. I don't think |
Right, but with this change, we turn a good code into an ugly one without any action from the author! We all speak about simplicity, try to decrease cognitive load, do things in the most straightforward and obvious way, but here we introduce a small change that will make thousands of (or hundreds of thousands) people think and try to separate type alias from a variable reading already written code. |
Isn't the final comment period over? |
@griesemer and I don't. But now looks like someone is shooting in my foot without me doing anything :) My point here is that the change will introduce more issues than value, at least now. |
That's true of any language or library change, though. For example:
That's certainly subjective. The 118 thumbs up and the 44 thumbs down seems to suggest that most people believe this has value. |
That's not what I'm talking about, so I'd say your examples are irrelevant. I'm not arguing the transition from
I'm from Russia, don't tell me about democracy :) |
Valid use of Let's stop this discussion. This issue has been up for > 2 years and there was plenty of time to comment and plenty of discussion on its merits and disadvantages. Thanks. |
No change in consensus, so accepted. 🎉 |
Reopening because this is not yet done. @makhov This change is completely backward compatible. If you want to discuss why that is, please do so on golang-nuts, not here. Thanks. |
Change https://golang.org/cl/351731 mentions this issue: |
@ianlancetaylor @griesemer Only in the sense that it still will compile. But software engineering is much more than writing code that compiles, right? Also, the issue has |
@makhov To repeat what @ianlancetaylor already said: If you want to discuss why that is, please do so on golang-nuts, not here. Thanks. |
Actually, this is done, sorry. |
For people who are landing on this issue now, note that the reasoning for acceptance is in #33232 (comment), which is in the middle of the issue thread and therefore hidden by default. |
Change https://golang.org/cl/369954 mentions this issue: |
Change https://golang.org/cl/382248 mentions this issue: |
Note, 2021-09-02: Now that
any
is an alias forinterface{}
, we have a special case that it can only be used in type parameter constraints. This proposal is now to remove that special case, allowing any, well, anywhere.This CL shows what it would look like if used throughout the Go tree.
- rsc
I would lilke to be able to declare any type with keyword any instead of empty interface, like rune means alias int32.
Such feature make language more readable , without polluting declarations with many empty interfaces. Imho any keyword is perfect for such alias.
The text was updated successfully, but these errors were encountered: