There is one thing which I think is quite clear from all the discussions that have taken place on this topic.
Having withstood years of criticism for the lack of generics in Go, the team are not going to be satisfied now with some under-powered or half-baked solution. They want to have as much power as possible within a coherent and (hopefully) easy to understand design. Now, it says in the draft design paper, that they considered using interfaces but couldn't find a clear way to represent operators using interface methods. Having tried to do that myself, I have a lot of sympathy with that position! So instead they came up with the idea of the type parameter(s) having to satisfy a number of requirements which could be expressed in 'normal' code and embodied in a new construct called a 'contract'. This idea is somewhat similar to 'concepts' in C++ as Ian has already pointed out. The problem is that many of us don't find the sort of code used in contracts (as currently envisaged) to be 'normal' at all and we're worried that the Go community at large will find them difficult to write (though a tool may help), understand or use. What you've just said, Jeff,enforces that view. So we've put forward some alternative proposals under the feedback system to try and address the perceived shortcomings of the present system, though it's not easy. I do however have faith that the Go team will eventually come up with something that will be reasonably powerful, understandable and consistent with the 'soul' of the language. Let's hope my faith is not misplaced. -- 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.
