On Thu, Aug 20, 2020 at 9:54 PM Ian Lance Taylor <i...@golang.org> wrote: > > Our intent here is that "any" will be available for all code. Yes, we > wouldn't do it if it weren't for its use as a type constraint. But if > we are going to do it for type constraints, there seems to be little > benefit to restricting it to only work as a type constraint. > > This is not, of course, a new idea, even in the absence of generics. > For example, https://golang.org/issue/33232. (My comment there was > that we would use interface{} less if we had generics, but of course > when we require type constraints then we actually wind up using it > somewhat more.)
I've seen objections that a language change for generics should not implicitly pull in a change to non-generic code. That seems fair. It may be the right thing to do, but it should be justified separately. So we're going to start with "any" only being accepted as a type constraint, and we can discuss making the name available for all uses separately, probably on issue 33232. Clearly adding "any" as a name accepted in type constraints is a step toward defining "any" for all code, but doing so isn't a requirement for generics. 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/CAOyqgcWr%2BrnZ7znmUe1MSMy1%2B%3DsXFxYbP1qt7%3DqnVXVVXXBE%3Dw%40mail.gmail.com.
