On Sat, Sep 8, 2018 at 6:10 PM, Rob Pike <r...@golang.org> wrote: > "A contract is a compile-time description of which types are permitted > for a polymorphic function or type." > > No, it's not. It's a collection of statement-like operations that must be > legally compilable, under restricted circumstances, by the type at the point > of instantiation, plus some special rules for cases that are hard to handle > that way. It's more of an illustration, an example, than a description. It's > implicit, roundabout, a little magical. > > I'm not criticizing the design, although it might sound like that, but there > is a certain lack of precision, of indirection, that makes this harder than > I hope it might be. And the first place to be precise is in the language > that defines what these new concepts are.
I said what a contract is, and I think I meant it. You are discussing how a contract is implemented. So perhaps the problem is that the implementation doesn't match the description. I guess that by special rules you mean the fact that == permits !=, and that < permits other comparison operators. Are there other special rules you mean? These rules seem to confuse people and I'm increasingly inclined to think that we should just drop them. But those rules aren't for cases that are hard to handle, they are just a shorthand, so perhaps I misunderstand what you are referring to. To me contracts aren't implicit or roundabout at all, at least not when it comes to which types they permit. They are very direct and straightforward, and they really could not be simpler. But clearly many people disagree. Perhaps we need to make them more complex by turning them into a list of explicit constraints. Ian -- 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.
