Good point. We will definitely want a warning before inadvertently changing the contract...
On Friday, 7 September 2018 10:58:51 UTC-4, Tristan Colgate wrote: > > You lose the ability to see changes of contract in your diff (which I > think is the thing I most want). > > > On Fri, 7 Sep 2018 at 15:56 Robert Johnstone <[email protected] > <javascript:>> wrote: > >> Hello, >> >> This seems more like a question for tooling. It has already been >> discussed that there should be a tool to read a body and provide a >> minimised or canonical contract. Perhaps we forgo writing the contract in >> code, and rely on godoc to determine the contract for the documentation? >> >> The contracts will be useful if they are used to constrain the >> implementation. >> >> - Robert >> >> >> On Thursday, 6 September 2018 18:18:13 UTC-4, soapboxcicero wrote: >> >>> If the contract for a type is entirely inferred in order to know the >>> types it accepts you have to read all of its code, every line. The >>> contract let's you boil that down to the salient points so you can >>> read line a few lines instead of a few hundred or a few thousand. >>> On Thu, Sep 6, 2018 at 3:15 PM Thomas Wilde <[email protected]> >>> 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. >>> > >>> > Thanks again and all the best, >>> > - Tom >>> > >>> >> > On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor <[email protected]> wrote: >>> >> >> >>> >> On Tue, Sep 4, 2018 at 7:41 AM, thwd <[email protected]> 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 [email protected]. >>> >> > 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
