4 ms·

"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,

"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?

karmakaze 2y ago
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.
- anamax 2y ago
  Lots of zeros is good. One big problem with null pointers is that there's only one of them. (One of a given type doesn't help.) Hoare's "NULL was my biggest mistake" rant proposed the wrong solution, namely no null.
  - earthboundkid 2y ago
    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.
tubthumper8 2y ago
In a non-lazily evaluated language (i.e. most languages not named Haskell) it would have to be done by passing in functions ("thunks")
HALtheWise 2y ago
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.
- earthboundkid 2y ago
  Here is the Godbolt. My assembly is weak, but AFAICT, it does not shortcircuit. https://godbolt.org/z/4z4Tr9Gjv https://godbolt.org/z/4z4Tr9Gjv
BoingBoomTschak 2y ago
[dead]

karmakaze 2y ago

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.

anamax 2y ago
Lots of zeros is good. One big problem with null pointers is that there's only one of them. (One of a given type doesn't help.) Hoare's "NULL was my biggest mistake" rant proposed the wrong solution, namely no null.
- earthboundkid 2y ago
  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.

tubthumper8 2y ago

In a non-lazily evaluated language (i.e. most languages not named Haskell) it would have to be done by passing in functions ("thunks")

HALtheWise 2y ago

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.

earthboundkid 2y ago
Here is the Godbolt. My assembly is weak, but AFAICT, it does not shortcircuit. https://godbolt.org/z/4z4Tr9Gjv https://godbolt.org/z/4z4Tr9Gjv

BoingBoomTschak 2y ago

[dead]