>
> Which at first seems like a good idea, but then unless "any" is built in
>> or this becomes a well-known idiom, it won't be as self-documenting. Other
>> people will have to look up the definition to see "oh, I see, this is just
>> short-hand for an empty constraint".
>
>
> I'm sure it would quickly become a well-known idiom, just like people know
> that "error" is "interface{Error() string}" or "fmt.Stringer" is
> "interface{String() string}".
>
That's fair enough -- I think you're right.
Actually the current use of "interface{}" is a bit odd because it is the
> only case where an interface is commonly used as an anonymous type rather
> than by an identifier.
>
Interesting point. My brain usually thinks of "interface{}" as a special
concept/syntax (and I suspect I'm not alone), even though I know it's not!
I assume that in current Go the empty interface is supposed to be an ugly
> duckling to discourage its overuse, but in a world with type parameters it
> will play an important role as the unbounded constraint and it should
> deserve its own identifier.
>
Very well stated, and I agree.
-Ben
--
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/a38219fb-9a33-48e1-929b-d17080bb9125n%40googlegroups.com.
