spec: allow 'any' for 'interface{}' in non-constraint contexts

[Lexkane]

Note, 2021-09-02: Now that any is an alias for interface{}, 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.

[alanfo]

I often use a type alias for this which isn't much extra work:

type any = interface{}

[ccbrown]

I agree with the sentiment that interface{} is terrible for readability, but I'm really hoping Go 2 has good enough generics to make nearly all uses of interface{} an avoidable anti-pattern. If that happens, an any type probably wouldn't be warranted at all. But if for some reason generics just completely fall through, sure, I'd support a builtin any alias. I do agree that it would increase readability.

[dotaheor]

I support this proposal, though not strongly.

In the early days of using Go, I often encountered the map[string]interface{} type, which is really confusing for a new gopher. I used it for about a year without knowing what it exactly means.

[whoiswentz]

I support this proposal too.

Its simple to implements and the readability becomes better

[Freeaqingme]

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.

[MaerF0x0]

Yes and on w/ what @Freeaqingme has said, we also must take care when creating different ways of doing the same thing because:

1. It makes tooling more difficult: now go tools have to support a new path to the same thing, and likely the users of said tools will expect output to match their chosen flavor of alias.

2. It reduces the token space for future golang iterations. Consider alternate uses for the any token in future iterations of the language. We lose the option of clear expressiveness if we choose to alias any to something that is already provided. Some random ideas of how any could be something else: it could refer to any length of array ([any]string) , it could refer to non ZeroValue elements in a slice ( any mySlice) like lodash's compact function .

The examples are unimportant, but the point should be clear. If we choose to make this our any then we're stuck with it for quite some time, likely for good.

[dotaheor]

Besides readability reason, less verbose and weird (esp. for new gophers) is another good point of this proposal.

@Freeaqingme
I began using Go by using Go templates to serve some web pages, I didn't need understand what interface{} is. I just needed to know I can assign any vale to it. any is far better for this purpose.

When a gopher later suddenly realizes that any is just interface{}, it is a viva moment, which in fact helps gophers understand Go better.

@MaerF0x0

It makes tooling more difficult:

any is just an alias of interface{}, there are many aliases in Go. If a tool can't handle such cases, it is a not qualified tool.

and likely the users of said tools will expect output to match their chosen flavor of alias.

This is not what a qualified tool should do.

It reduces the token space for future golang iterations.

Builtin identifiers are not keywords, users can shadow them as needed.

[Freeaqingme]

@dotaheor

I just needed to know I can assign any vale to it. any is far better for this purpose.

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.

@MaerF0x0

We lose the option of clear expressiveness if we choose to alias any to something that is already provided.

We still have 'whatever' and 'anythingReally' as alternatives 😋