Considering there are already many concerns about complexity introduced by generics, the situation will be even worse when generics arrive without eliminating the built-in magic stuff. Then is generics really worth the trade-offs? Does the gain outweigh the pain? 在 2018年9月18日星期二 UTC+8上午8:02:41，alanfo写道： > > 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* >> >
-- 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.
