> On Oct 25, 2018, at 6:45 AM, Marvin Renich <m...@renich.org> wrote: > > The most powerful feature of the contracts described in the original > design draft is the ability to describe interactions between two types > in a type specification. Your proposal doesn't seem to allow this.
See the section of my gist about Contracts on Multiple Types. The contract G there is exactly equivalent to the one in the design draft. > Also, you seem to be trying to use "familiar" Go constructs for your > contract body, but you mix types, fields, and operators at the same > syntactical level. This is bound to be a source of significant > cognitive load both when writing and reading contracts. I’ve decided to drop operators from my syntax for structural contracts. The only one that was really needed was ==, and it would have to be a little magic in order to allow using the type as a map key as well. So now I just have a built-in contract `comparable`. The only type names that are used in structural contracts are interfaces, and they are used in the same way as in an interface that embeds another interface. So that should limit the cognitive load somewhat. > Andy, if your proposal is just taking the design draft and replacing the > contract syntax, then I like it, but I believe my syntax is > significantly better. Yes, that’s my intention. I personally like how much my proposal can accomplish with so little new syntax. (Though it’s actually more new syntax than the design draft… but I expect it’s quite a bit easier to read and write.) Andy -- 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.
