Even if it were possible to eliminate the built in generic stuff, I think it would be a bad idea to do so.
For better or for worse it's now part of the fabric of the language and just about every program ever written in Go 1 would have to be fixed if it were replaced. Also there are many in the community who don't want generics and will probably avoid using them if they can. If that's their choice, then I think they should be allowed to make it and carry on as they are. Alan On Monday, September 17, 2018 at 10:44:16 PM UTC+1, Michael Jones wrote: > > Firstly, my compliments to Russ, Robbert, and Ian, for patience, > thoughtfulness, and insight. Whatever the best answer is, no doubt your > intellectual process is an excellent way to find it. > > My comment is a meta-comment, a question/proposal: *if generics arrive in > Go 2 then can we "go fix" Go 1 code to use this mechanism to replace the > existing built-in magic generics in Go?* > > For example, if it is possible to implement *map* in ordinary library > code, then should it be the rule to do so? The heop is that accepting this > as the test for goodness simultaneously proves capability and reduces the > instances of magical compiler support in favor of a new orthogonal feature, > perhaps making Go 2 conceptually smaller, which seems a good goal. > > -- > > *Michael T. jonesmichae...@gmail.com <javascript:>* > -- 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. For more options, visit https://groups.google.com/d/optout.
