"Note that because cmp.Or cannot do short-circuit evaluation, this will compare the product name and price of each item, even if the customer name is different, which makes doing so redundant."
Is the problem really the lack of short-circuit evaluation, or the fact that passing arguments to the function requires evaluating all arguments first? I.e. is it even possible to write a function which wouldn't evaluate all args before calling?
I loosely read it as both: Using cmp.Or does not short-circuit evaluation.
The other bit was also interesting:
> According to the proposal, the built in constant `zero` would be available in generic functions for return or comparison. However, after the proposal was accepted, it was retracted due to continued community push back against the idea of having both `nil` and `zero` in the language.
So instead of having a `zero` we have many zeroes `nil`, 0, `""`, etc. Go really eschews abstractions.
I think it would be better if Go had nilptr for pointer types and "nil" only applied to interface types. That would fix the problem of "why did I return nilptr but the value != nil?" But Go should also have a named zero value that applies everywhere, or at least an operator like ? that compares anything to zero.
Presumably cmp.Or is short enough that it will usually be inlined by the compiler, at which point any side-effect-free calculations can be short circuited. I don't know in what circumstances cgo actually will perform both of those optimizations.
And look how short this code is thanks to languages sane defaults. In Rust you would need T : Default + PartislEQ, and all that jazz