Skip to content
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: Go 2: add alias for interface {} as any #33232

Open
Lexkane opened this issue Jul 22, 2019 · 16 comments

Comments

@Lexkane
Copy link

commented Jul 22, 2019

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

This comment has been minimized.

Copy link

commented Jul 22, 2019

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

type any = interface{}

@ianlancetaylor ianlancetaylor changed the title Proposal Go2: Add alias for interface {} as any proposal: Go 2: add alias for interface {} as any Jul 22, 2019

@gopherbot gopherbot added this to the Proposal milestone Jul 22, 2019

@gopherbot gopherbot added the Proposal label Jul 22, 2019

@gopherbot gopherbot added the Proposal label Jul 22, 2019

@ccbrown

This comment has been minimized.

Copy link

commented Jul 23, 2019

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

This comment has been minimized.

Copy link

commented Jul 23, 2019

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

This comment has been minimized.

Copy link

commented Jul 23, 2019

I support this proposal too.

Its simple to implements and the readability becomes better

@Freeaqingme

This comment has been minimized.

Copy link

commented Jul 24, 2019

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

This comment has been minimized.

Copy link

commented Jul 24, 2019

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

This comment has been minimized.

Copy link

commented Jul 24, 2019

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

This comment has been minimized.

Copy link

commented Jul 25, 2019

@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 😋

@changkun

This comment has been minimized.

Copy link
Contributor

commented Jul 25, 2019

Is there anyone cloud explain the historical reason of why interface{} is designed as interface{} rather than anything else?

@dotaheor

This comment has been minimized.

Copy link

commented Jul 25, 2019

@Freeaqingme
any will not be a keyword, it will be just a builtin identifier, just like, rune and byte, etc.

interface{} means an interface type specifying no methods, which happens to make it act as the any type. interface{} is not a bad thing generally, but using it as the any type is bad for new gophers. It confuses many new gophers.

@fzipp

This comment has been minimized.

Copy link

commented Jul 29, 2019

@Freeaqingme

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.

@changkun

Is there anyone cloud explain the historical reason of why interface{} is designed as interface{} rather than anything else?

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:

func f(a interface{Foo(); Bar()}) {
    a.Foo()
    a.Bar()
}

Analogous to how you can use anonymous structs anywhere a type is expected:

func f(a struct{Foo int; Bar string}) {
    fmt.Println(a.Foo)
    fmt.Println(a.Bar)
}

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.

@Freeaqingme

This comment has been minimized.

Copy link

commented Jul 29, 2019

@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.

@sirkon

This comment has been minimized.

Copy link

commented Jul 30, 2019

@Freeaqingme

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.

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.

@y-usuzumi

This comment has been minimized.

Copy link

commented Aug 1, 2019

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 True in place of otherwise.

It's only good if there's a single GOOD way of doing things.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2019

If we are able to add generics to the language, then I suspect there will be many fewer cases where people write interface{}, so the alias would have correspondingly less value. Putting on hold pending a decision on generics.

@conilas

This comment has been minimized.

Copy link

commented Sep 13, 2019

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):

func add(a interface{}, b interface{}, action fn_type<args>){
  return fn(a, b) -> {
    fmt.Printf("%v %v", a, b)
    action(a, b)    
  }
}

The top type would be good in this case instead of writing interface{} either way, so I think this proposal still have some value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.