I wish I could be pointed to such discussion. > The language authors omitted this functionality for a reason. One of the > reasons is that arrays and slices are similar, and changing their > comparison semantics seemed confusing. >
https://blog.golang.org/slices specifically mentions that arrays and slices are not similar. The spec does as well. Currently, slices do NOT compare. I am simply arguing that they could very logically. The "==" operator is only overloaded in the case of strings currently but that's truly an implementation detail. Strings are values but their implementation is of a reference type. To get the value behaviour back, the comparison is weakened to only take into account the underlying array values and not where they are located. This probably for optimisation purposes. Other than that, there is a whole consistency to the language and how it works. I simply would like that consistency extended. My main argument is that without specifying the logical "comparison" behaviour for all reference types,* interface comparisons become unsafe*. It's perhaps even a *bug*. N.B. I gave my definition of a reference type which is the definition I would choose for Go. It does not have to be identical to what is found in other languages. In any case, there probably needs to be a way to distinguish between types that hold a reference to another datastructure from those that don't. -- 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.
