Having an external tool to write/validate contracts sounds more like a hack than a proper solution. It's kind of the same reason why I dislike generators. You have to learn an "alien" syntax that doesn't quite fit the rest of the language. If we are going that way, why not implement a full fledged pre-processor like C++ and implement templates? I understand the reasons behind the contracts, and this time I'm not questioning the existence of contracts but the "how" it is implemented.
Best, Dani Em ter, 11 de set de 2018 às 13:22, <alan.f...@gmail.com> escreveu: > 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. > -- 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.
