The proposal was declined, so no need to respond. Some responses inline below. Thanks so much for your feedback, Axel. :)
On Thu, May 5, 2022 at 11:39 AM 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > 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 acknowledged that a trade-off exists, not that I agreed that performance outweighed all other considerations, although I would weigh performance costs very highly. The point was moot since function values can have multiple addresses. In the email you're responding to, I explained that arguments are supposed to balance conflicting principles. Performance vs. consistency vs. simplicity vs etc. is an example. > 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. > > Sure. You have to weigh various aspects according to various principles, and make a decision. The explicit, concrete weighing of these aspects is what has been missing from the counter arguments. That's been my point. "Complexity is bad" is useless on its own. "This would require XYZ changes to the spec, PQR changes to the implementation, users would have to keep ABC in their head now as opposed to DEF when having to roll their own comparisons..." is an actual analysis of complexity, which is actually tractable as a premise in an argument. "Users don't get compiler errors when they try to compare slices, we don't have to maintain a FAQ entry about it, we don't have to point users to it, they learn how it works when they learn how slices work and how == works for all types, it's constant time and clearly defined..." is something that can be weighed too. Now we can try to pin down specific aspects or constraints that force the decision one way or another, or feel out which adds up to more value, etc. It's not a simple "my principle vs. your principle" slugout. > 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. > > That sounds like it would have been a promising counter argument :), although I wonder if it would have survived the point that Go programmers are expected to learn what == does for each type. > 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¹. > Only insofar as they don't understand slices at all. If you know they point to an array, and copying them around is a lightweight operation that doesn't copy the actual array, then IMO it becomes natural to think of slice comparisons working like they do for Slice1000. Hence why I used that example. > 2. Doing that has technical problems making it prohibitive (e.g. the > existence of cyclic data structures). > Deep comparisons do, not shallow ones. > 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² . > Shallow comparisons :), for reasons like what you just listed, e.g. cyclic data structures. Shallow comparisons are constant time. Map lookups won't potentially take a long time. Deep comparisons make slices in effect mutable. > 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. > > Define badly. [1] Note that you mentioned Rust, Ruby and Python to support comparisons on > their respective equivalents. Their comparisons all behave this way. > This is an excellent point! I would have wondered if there's room for a difference in shallowness/deepness while still being consistent by providing *some* kind of comparison. > [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. > > Sure. reflect.DeepEquals. Some kind of equivalence === operation. Arbitrary code. I wouldn't want to limit users. > >> 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 a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/b-WtVh3H_oY/unsubscribe. > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFYJ%3DHFYCBuaqRbjmD7H39gdihYObrwcdBTidqfJt1PJg%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/CAKbcuKjMEtC-8CJmtV6TUWOn3ijej2O-echNB92gPQDq%2Bd1Pfg%40mail.gmail.com.
