Ian, Here's a few points which I noticed when reading through the draft design which I thought people might have trouble getting their heads around:
1. The use of untyped numeric constants where you might need to specify the exact value needed to get the thing to work. I don't think anyone could describe that as obvious. 2. The inability to specify in a simple way that a method doesn't have a return value, can take a variable number of arguments or (a particularly nasty one) to distinguish a method call from a struct field of function type. I thought folks might thrash around quite a bit trying to figure these out before they released they'd have to use a conversion to a suitable interface type. 3. The difficulty of distinguishing between methods which take a value and a pointer receiver. 4. The 'nil' value problem. In C# they overload the 'default' keyword (i.e. default(T)) to produce the default value (all bits set to zero) for a type T. Maybe we could do something like this? On Thursday, September 6, 2018 at 8:52:03 PM UTC+1, Ian Lance Taylor wrote: > > On Thu, Sep 6, 2018 at 12:05 PM, alanfo <alan...@gmail.com <javascript:>> > 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.
