Ian, Thanks for taking the time to read through my feedback on this matter. You'd didn't miss much by not reading the earlier version as I'd tried to marry the 'type group' idea with interfaces and ended up with something which was not really coherent.
It is, of course, unfortunate that one needs such a large number of groups to cover all combinations of the built-in operators and conversions (particularly as many are just unions of other groups) - and there'd be even more if $slice and $chan were added! So, yes, there'd be a lot to learn but there'd also be a lot to learn to write 'full-blooded' contracts effectively some aspects of which are quite subtle. What attracted me to the type group idea was that, if you were writing a generic function, you could just say to yourself what types do I need to cover with this and, in the majority of cases, you could simply choose the appropriate group for your parameter(s) and the job would be half done. You wouldn't need to worry about which operators and/or conversions were used as you (and the compiler) would know immediately what was supported. I suspect that, if you can make contracts work in the way the draft envisages, then folks will write the function first and then write the contract afterwards to try and fit in with what they've done. Tooling would, of course, help though I wonder whether it will be able to deal with all the subtleties? Anyway, many thanks for all the work that Robert and yourself must have put in to present us with a coherent design. It's certainly stimulated some discussion amongst gophers and plenty of decent feedback including great contributions from Axel and Matt which I hope you'll also cast your eye over - they don't use as many type-classes as me ;) Alan -- 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.
