It looks to me one point of contention on using interfaces instead of contracts is the fact that now interfaces have to support type lists but only when used as contracts. This, no matter how you slice it, looks ugly.
Now type lists are there to support built-in operations like operators in general and range support. there is a finite (and relatively small) set of combinations of types that make sense. Also there is already the intention of providing "contracts" like Comparable in pre-existing libraries. There is also precedent for "magical" things in the language (range can operate on slices of any type). So, with all that in mind, wouldn't it be possible for the language to offer all the possible reasonable type combinations as built-in contracts in a way that they could be embedded in other interfaces? They would be a bit magical as their constraints are, under the hood, on types (not methods), but I guess this would make things less ugly. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEd86Tz%2B6vfp1C_kFA82Mw5z__%3D5SLrc%3Dnu3od1AKBVCCRtBPQ%40mail.gmail.com.
