This would disallow contracts on presence and type of fields right? The existing design permits them, and disallowing them feels a little arbitrary.
On Tue, 4 Sep 2018, 17:17 roger peppe, <rogpe...@gmail.com> wrote: > On 4 September 2018 at 15:41, thwd <sedeveloper...@gmail.com> 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 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.
