On Wednesday, October 17, 2018 at 11:12:19 AM UTC-4, Ian Denhardt wrote: > > My instinct here is to be conservative; we've got a boatload of use > cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail > for operators after that. Eric's proposal makes it trivial to add more > operators to the list of allowed ones, but it's always harder to go the > other way. So my inclination would be to implement this for operators > like `<` that are kinda screaming at us, and then build some experience > with that. >
I concur fully with this. The spirit of my proposal is to do something transparent, minimal, and lighter-weight than any of the heavyweight contracts proposals, then find out by experience what more we need, if anything. I am directly opposing approaches that incur large increases in the syntactic and semantic complexity of the language up front at the cost of setting us all up for disappointment when they turn out to be inadequate or have lurking boojums. -- 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.
