On Thu, Sep 6, 2018 at 12:05 PM, alanfo <alan.f...@gmail.com> wrote: > > So, yes, there'd be a lot to learn but there'd also be a lot to learn to > write 'full-blooded' contracts effectively some aspects of which are quite > subtle.
I would like to more clearly understand which aspects seem subtle when reading the code. Where does it become confusing? > I suspect that, if you can make contracts work in the way the draft > envisages, then folks will write the function first and then write the > contract afterwards to try and fit in with what they've done. Tooling would, > of course, help though I wonder whether it will be able to deal with all the > subtleties? My sense is that *if* we can write a compiler that is able to type check a contract, which is unproven, then it will automatically follow that we can write a tool that deals with all subtleties. 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.
