I don't think saying that is is productive. contracts are more than just "identifiers used as constraints", they are also a syntactic construct to specify those. I specifically don't allow that and that's the whole point I'm making. So this doesn't seem like a particularly nice way to have a discussion.
But yes, if it makes you happier, we can call them "contracts", allow to embed them into interfaces and remove contract declarations from the design (or, allow embedding interfaces into contract-declarations, remove the "type-checking function body" idea and instead define a set of base-contracts you can use for operators) and you'd end up with pretty much my design. On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam <jbamster...@gmail.com> wrote: > > > On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote: >> >> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam <jbams...@gmail.com> >> wrote: >> >>> The problem is that this program seems to type-check, but it is invalid. >>> The == operator is specified to work on operands of the same type, and it >>> is being used on operands of different types. >>> >> >> Good point. I have to think about it. An ad-hoc solution, FWIW, would be >> to only take into account (or allow) pseudo-interfaces for type-constraints. >> > > The draft design has a name for those: contracts. > > -- > 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.
