On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote: > > I think the thing everyone who likes operator overloading like mainly is > being able to do infix and postfix syntax, instead of only prefix > (function). >
It's good that you brought that up, because another issue I remember from C++ V1.0 days, is that operator overloading did not allow for changes in operator precedence, an arbitrary sop to some weird decisions taken in earlier centuries. What I see as pertinent here, is that precedence is yet another "type" property, this time not of the arguments to an operator, but the operator itself. As I pointed out in private correspondence to Ian Taylor, the entire mess of arithmetic operations ought to be delegated to an APL-like interpreter and all the complexities, of which being "generic" functionality is not the only one, becomes one less problem for the Go compiler. If APL is too obscenely obscure in the Go context, no doubt there will be alternatives: it did not take Rob Pike long to produce Ivy. Of course, we also have indexing, indirection and a few other features of Go whose role could be examined and formalised, perhaps more successfully once the obscurity contributed by the arithmetic features is expelled from the language. Ian's response will remain with me for as long as I live, as I think it is very apt summary: that would not be Go. I entirely agree with him. > But then also what do you do about interfaces that also implement an > operator interface? I'd guess biggest reason to not do it is > > 1) no human readable distinction between actual operations and one has to > decompose the code quite a lot as both types have to be known before you > can attach it to an interface > > 2) there is very few cases where being able to use infix operators makes > that much difference to readability, it's like you want some mathematical > notation but it's still all in lines. Chaining pass-through methods works > just as well and the types are much easier to identify before you even > fully parse it. > > Once we treat mathematical expressions as orthogonal to the language, we get brand new choices, possibly opportunities: what is Boolean? What is a string that is not an array? Etc. A whole new chapter opens, for better or for worse. Lucio. -- 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.
