On Tuesday, September 11, 2018 at 11:35:05 AM UTC-4, Ian Davis wrote: > > > Recent conversations here and around the proposal suggest that the type > system isn't strong or clear enough to convey the kinds of constraints that > we want to use. Personally I am not a fan of having nonsense, unexecutable > code in contract blocks but I do like the general approach. I wonder > whether a DSL is needed to make assertions stronger. Another alternative > could be to borrow more from C++ and make contracts boolean functions that > must return true although this loses the advantages of just reusing the > compiler's type checking since the contracts would have to be evaluated at > compile time too. >
I think you hit upon the issue I am having with contracts. I generally understand the intent of the approach. But, when I look at the contracts themselves, it is very unclear to me as to what types are and or not permitted by the contract. Interfaces do a good job in my opinion of explicitly stating what is required to satisfy the interface. Contracts as currently proposed seem to hide too much, thus making it very difficult for more casual programmers to discern what the contract is attempting to convey. I appreciate there is a balance between an implementation that is too verbose and an implementation that is too concise. The current contracts may lean too far toward conciseness. -- 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.
