On Thu, Sep 6, 2018 at 3:16 PM Thomas Wilde <sedeveloper...@gmail.com> wrote:
> Thanks for the response. I think the question then becomes: if the syntax > in contract bodies was an unrestricted Go block, then why do I need to > repeat my function's operations in a contract? > > If the syntax of contract bodies is free, then the Go compiler could > easily deduce all my constraints from a function body directly -- no need > for a separate contract. > Having a separate contract constrains *both* the caller and the implementation. If you infer a contract from the implementation, it's trivial to break all your callers by accidentally adding new assumptions to your implementation. With a contract in place, changing the implementation in an incompatible way is a compile error - "hey, your implementation is trying to do stuff your contract doesn't allow!" This makes it hard to accidentally break your callers, because you have to take an explicit action to change the contract, if you want to allow your implementation to do more things. - Dave > > Thanks again and all the best, > - Tom > > On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor <i...@golang.org> wrote: > >> On Tue, Sep 4, 2018 at 7:41 AM, thwd <sedeveloper...@gmail.com> wrote: >> > >> > From the draft proposal I gather two open questions: >> > - How free or restricted should contract bodies be? >> >> I believe it's useful to have contract bodies simply be arbitrary >> function bodies, as the current design draft suggests. This is >> because I believe that is conceptually the simplest choice. You don't >> have to remember two different syntaxes, one for code and one for >> contract bodies. You just have to remember a single syntax, one you >> must know in any case to write any Go code at all. >> >> > - How many implicit constraints can be inferred from usage? >> >> As few as we can get away with. >> >> >> > 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. >> >> People do suggest that that will happen but I think it is extremely >> unlikely in practice. It's obviously a terrible coding style, and >> almost all generic functions have trivial contract requirements. >> >> 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. > -- 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.
