Personally, I'm not afraid of writing contracts manually. I suspect that in the vast majority of the cases the contract will be clear and pretty trivial. In fact, I think it could be a productive part of the design process to consider what your generic function minimally needs and write the contract first. In some cases it will could in a better implementation. If the contract is very complicated it could indicate an overall design issue. If the contract is generated after the code is written it could result in unnecessary restrictions based on how the code was written. OTOH, If the contract is carefully written first, and it turns out that implementation requires something more than expected, then that could spur some productive thought on the implementation, or the underlying assumptions. Either way, IMHO, the result would probably be better code.
I also think that a tool for updating contracts based on code changes could make it easier to .... well to update contracts based on code changes. Changing a contract to be more restrictive is, by definition a breaking change, and a pain point for users of the generic function(s). Making it easier to do does not seem like a win to me. I'm not strictly against such a tool, but it is worth considering. Only time will tell if writing contracts is truly a hard problem, but my gut says that, in the end, it will not be that big of an issue. Frankly, I'm more concerned with "reading" contracts ... but that's another story. On Wednesday, September 5, 2018 at 4:57:08 AM UTC-4, Tristan Colgate wrote: > > One thing that has been occurring to me on this is that it is probably > reasonably practical to have a tool infer and update the contracts. The > tool could limit itself to a restricted set of statements, without the spec > needing to actually limit them directly. > > On Wed, 5 Sep 2018 at 09:17 thwd <[email protected] <javascript:>> > wrote: > >> If you can't use operations not explicitly stated in a contract: the more >> reason to copy-paste a function body into a contract. >> >> What I mean by implicit constraints is what the draft calls "implied >> constraints". >> >> -- >> 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.
