On Thu, May 5, 2022 at 7:32 PM Will Faught <will.fau...@gmail.com> wrote:
> Yeah, it's a trade-off. I can understand that it's not worth it. > I find it confusing to me that you seem to be willing to allow the existence of tradeoffs on the one hand. And on the other you treat most arguments as all-or-nothing questions. Like: I think what you've put forth as counter arguments are instead *principles*, > like "simplicity is good," "complexity is bad," "changes have cost," and so > on. Principles aren't themselves arguments, so they can't be used as > premises in an argument. > > 1. Complexity is bad. > 2. This change increases complexity in one area. > Therefore, 3. This change is bad. > > > is not a good argument because "complexity is bad" would rule out all > changes, and it would be inconsistent with the past and recent behavior of > the Go Team. > "Complexity is bad" is indeed in the "contra" column for most changes. That doesn't rule them out though. It just means they have to justify their complexity. There are many, individual arguments at play here. Each one individually doesn't lead to the conclusion. And taking each one individually out of context and applying it in totality as the only deciding factor leads to ridiculous results like this. But *taken together*, they can paint a picture that the downsides of adding comparison for certain types outweigh their benefits. And that it's different for other types. Pointers and Slices have commonalities, true. But that doesn't mean "if you can compare pointers, you should be able to compare slices". They also have differences. And it's entirely reasonable, that the downsides for adding a comparison for slices do not apply for pointers, or apply to a lesser degree. And similar for benefits. All that said, assuming you agree, what is your full counter argument, or > set of counter arguments, to my initial argument for slice and map > comparisons, shaped by the principles you've listed? It doesn't need to be > in a rigid numbered list format, but it should be obvious how your counter > arguments could logically fit into that format. > One argument goes roughly like 1. We believe most people would expect comparison of slices to compare the contents of slices/maps, not the "shallow" comparison you suggest¹. 2. Doing that has technical problems making it prohibitive (e.g. the existence of cyclic data structures). 3. Even *if* we would add a "shallow" comparison instead, there are still open questions where it is hard to say what the "right" answer would be² . 4. It is better not to have any comparison, than one which behaves badly. The programmer can always be explicit about their intentions, if need be. [1] Note that you mentioned Rust, Ruby and Python to support comparisons on their respective equivalents. Their comparisons all behave this way. [2] This alone would probably not prevent us from doing it, but given that we'd want a different notion of comparability anyways, it still matters. > Ian >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAKbcuKh_vGQTjtuBECxDJM%2BuHs5eiRpw2iq-%3DK77YyeUpcR%2BfQ%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAKbcuKh_vGQTjtuBECxDJM%2BuHs5eiRpw2iq-%3DK77YyeUpcR%2BfQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFYJ%3DHFYCBuaqRbjmD7H39gdihYObrwcdBTidqfJt1PJg%40mail.gmail.com.
