On 4 September 2018 at 15:41, thwd <[email protected]> wrote: > From the draft proposal I gather two open questions: > - How free or restricted should contract bodies be? > - How many implicit constraints can be inferred from usage? > > If too much syntax is allowed in contract bodies and no implicit constraints > are gathered: > people will copy and paste function bodies into contracts to cover all > constraints. > > If only restricted syntax is allowed in contract bodies and a lot of > implicit constraints are gathered: > people will write empty contracts and hope for the compiler to pick up on > all the constraints. > > These two questions are related.
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". 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. cheers, rog. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
