Hi all,
A few people have raised concerns about "encouraging" use of any instead of
interface{}, on the grounds that it is not idiomatic Go. I just wanted to
acknowledge that yes, it's not idiomatic Go today, but that's true of
essentially every language change. Thinking about future usage is a good
consideration, but we define idiomatic by convention, and that convention
is heavily influenced by what is and is not in the language. It is OK for
the convention to shift, and here it almost certainly would.
Many years ago, there was no rune type in Go. We used int instead, as in:
runes := []int("hello")
It would certainly not have been idiomatic at the time to instead define
type rune = int
and then write code like:
runes := []rune("hello")
The argument against doing this would be that everyone expects to see []int
instead, and that introducing your own custom definition here for a
standard language concept adds to the conceptual burden for readers by
making your code look different from everyone else's, forcing readers to
search out the definition of "rune" to understand the code. (It was equally
non-idiomatic to define "type error = os.Error" before we had the
predefined error type.)
The same argument that applied back then to a custom rune = int or error =
os.Error alias applies today to a custom any = interface{} alias: it's not
a good thing to make your code gratuitously different from others' code.
But just as "type rune = int" being non-idiomatic did not
preclude introducing a *standard* predefined rune type alias, the fact that
"type any = interface{}" is non-idiomatic today does not preclude
introducing a standard predefined any type alias. It becomes idiomatic by
making it part of the language. Then everyone can use it, and no one's code
is gratuitously different.
It's also true that older Go code using interface{} will look different
from newer Go code using "any". But that is true of every language change.
New code that omits semicolons looks different from old code that doesn't.
New code that writes 0o777 looks different from old code that writes 0777.
And so on, for every change we make. This is fundamental to languages
evolving: new code and old code look different. (Part of minimizing
the need to code switch is providing tools to help update old code to look
new; we've done that repeatedly in the past and would undoubtedly do that
here as well.)
A few other people have raised concerns about not seeing the word interface
and therefore not realizing "any" is an interface type and potentially
getting confused. This is also a good consideration, but we already have
many interface types that don't use the word interface, most notably the
predefined type error, but also io.Reader, http.ResponseWriter, and so on.
People learn early on that not all interface types say interface in the
name. I don't expect that "any" will not be any harder to learn than the
others.
In any (ha!) event, it's probably more important to focus on the larger
semantics of generics than this specific color, attractive though it may be.
Best,
Russ
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAA8EjDQvv95bweUeWK6jDA2aQ2F1uuZh5MCRZuTHJ%2BBHMCj2-Q%40mail.gmail.com.
