On Sat, Sep 8, 2018 at 2:23 PM, jimmy frasche <soapboxcic...@gmail.com> wrote: > > I get that it avoids introducing those properties directly into the > language but it also locks the language into those properties. You can > never change https://github.com/golang/go/issues/19113 after > introducing contracts because there could be a contract somewhere that > uses 1 << u instead of contracts.Unsigned.
This is an interesting point but I'm not yet convinced. The effect of adopting issue 19113 would be that the contract would accept types that it previously did not accept. But any polymorphic function using that contract would still compile. And any call to that polymorphic function would still compile and work correctly. So what you are arguing is that we could not make a change that would cause a contract to accept additional types. I've been questioning why it is important for a contract to reject types, and I'm still questioning that. 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.
