I actually mean something different. The bad with *any* in builtins is
there will be questions "why you use interface{}" if there's builtin *any?*",
etc. I mean these will be different AST nodes, there will be
*type GenericAny struct {*
* Name *ast.Lit*
*}*
and
*type Generic struct {*
* Name *ast.Lit*
* Type *ast.Ident*
*}*
the type system then will see if there's type *any* in a scope and will
replace it with a type info node for that type, otherwise, *interface{}*
will be used. A bit ugly and I am anything but sure if they will be really
happy with that. Still a variant.
воскресенье, 26 июля 2020 г. в 02:11:18 UTC+3, Carla Pfaff:
> I don't see why it should be in the grammar. Just a regular type alias for
> interface{} in the builtin scope, a regular predeclared identifier. It
> wouldn't break anyone's code. If someone already has an 'any' type or
> variable in their package their version shadows the builtin one, and they
> can still use interface{} as a generic type constraint. At least that's how
> it works with other builtin type aliases like 'rune':
> https://play.golang.org/p/KRX3fIBV9qW
--
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/bc7dd36b-0d5a-4ade-aa41-344ba7fb1bacn%40googlegroups.com.
