On Tue, Sep 4, 2018 at 9:17 AM, roger peppe <rogpe...@gmail.com> wrote: > > As I understand it, if a contract doesn't allow it, you won't be able to do > it. > That is, the contract is scanned for "operations" (however they might be > defined), and then it will be a compiler error if a function uses an operation > not permitted in the contract. > > An empty contract body permits no operations other than those available > on every Go value (copying, taking address of, passing as a parameter, etc). > > So I'm not entirely sure what you mean by "implicit constraints".
The current design draft does suggest a couple of implicit constraints: 1) Using any of "==" or "!=" implies that the function body can use either operation. 2) Similarly, using any of "<", "<=", ">=", ">" implies that the that function body can use any operation, as well as "==" and "!=". I'm not sure whether this is a good idea or not. > That said, it is my opinion that it is very hard to read an arbitrary > constraint > body and infer the set of possible operations that can be performed. > It's not that much easier to look at it and work out what types might satisfy > the contract either. > > My suggestion (that I've written up here: > https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is > that, at least to start with, we allow only a very restricted set of > contract bodies. > > Specifically, in my suggestion, every statement in a contract body > must consist of exactly one expression. > Identifiers in the expression can only reference types or the > contract's parameters. > The expression must reference at least one of the contract's type parameters. > The expression must exactly one of: > - any unary or binary operator (but not a field or method selector) > - a function invocation > - a type conversion > - an index expression > > Intuitively I'd like a single statement in the expression to specify > exactly a single operation which should be clear from the operands of > the expression. > > Thus if you look down the contract and you don't see the operation > you're looking for, then you can't do it. I think that the hypothetical contract simplifier tool (gocontracts) should turn most contracts into exactly what you say. 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.
