On Friday 9 August 2024 at 06:19:22 UTC+6 Jolyon Direnko-Smith wrote: Second, you don't need to implement a custom == operator to compare custom struct types; the implementation of == in Golang already covers the comparison of structured value types in a logical, intuitive and type-safe manner.
I would agree, except there is no == operator defined on slices, and I'm not really sure why that is. The semantics I would expect are straightforward: i.e. length is the same, and the first 'len' slice elements compare as equal, recursively if necessary. (*) Apart from that, I see no particular advantage of tuples over structs. They might be a bit more verbose in some cases, but literals can look like tuples already: https://go.dev/play/p/kuGW_Mv8ZZf Being able to access elements by name rather than position is also a benefit IMO. (*) Aside: having == defined on all types would be a nice feature which I think would lead to simplification overall - like getting rid of the issue where comparing interface values can panic when they are the same type. AFAICS, only maps might be problematic, but even then the potential semantics seem straightforward. If they are the same map then they are trivially equal, and if they are different lengths they are trivially unequal. Otherwise you would iterate over all keys in A, and compare values with corresponding elements in B. But I'm sure this must have been discussed to death already. -- 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/fc75e31c-2805-49a0-ac7e-cac316eb0f66n%40googlegroups.com.
