On Thu, Dec 24, 2020 at 4:04 AM LeoY <minh...@gmail.com> wrote:
>
> Thank you, Ian. Is there any desire to avoid introducing a new predefined
> name? Is it going to be just an empty interface definition in one of the core
> language modules similar to the following:
>
> type any interface { }
>
> If this is a case would be syntactically similar to have a function
> declaration that uses empty interface explicitly:
>
> func F[T interface{}] (p T) { ... }
Yes, the predeclared name "any" is an alias for "interface{}". In the
current design draft the name "any" is only recognized as a type
parameter constraint. It's not recognized in general. If the
generics proposal is adopted, then it would be worth considering
making "any" an ordinary predeclared type alias, similar to "byte" and
"rune". But that will be a discussion separate from generics in
general.
In practice we believe it will be common to have type parameters
without constraints. In particular that is how generic containers
will work. Always writing [T interface{}] did not seem ideal, so we
introduced "any" to permit writing [T any]. Adding a new predeclared
name is definitely a cost (the generics design draft also introduces
"comparable"). In this case it seems to us that the benefit is worth
the cost.
Ian
--
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/CAOyqgcVGzUzjp2pETGyKhNLNXhe78aN0GQTLXiKkf6_V3scEYA%40mail.gmail.com.
