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 <sedevel...@gmail.com 
> <javascript:>> 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 <ia...@golang.org 
> <javascript:>> wrote: 
> >> 
> >> On Tue, Sep 4, 2018 at 7:41 AM, thwd <sedevel...@gmail.com 
> <javascript:>> 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...@googlegroups.com <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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to