3 ms·

> In all other cases, like any(2) == 2, we compare the values. But any(nil) == nil returns true like you'd expect. The reason that any((*int)(nil)) == nil is

> In all other cases, like any(2) == 2, we compare the values. But any(nil) == nil returns true like you'd expect. The reason that any((*int)(nil)) == nil is false is the same reason that any(uint(2)) == 2 is false: interfaces compare values and types.

aatd86 1y ago
that's another thing that makes it difficult to fix. Same thing here. 2 is an untyped constant so it should have returned true. (even if int is the default picked on short assignment) any(uint(2)) == int(2) should return false indeed however.
- kbolino 1y ago
  Untyped constants deserve an entry of their own in a list of the language's subtleties, that's for sure. Importantly, untyped constants don't exist at runtime, and non-primitive types like interfaces aren't constants, so any(uint(2)) == 2 can't behave the way you want without some pretty significant changes to the language's semantics. Either untyped constants would have to get a runtime representation--and equality comparisons would have to introduce some heavyweight reflection--or else interfaces would have to be hoisted into the constant part of the language--which is quite tricky to get right--and then you just end up in a situation where any(uint(2)) == 2 works but x == 2 doesn't when x turns out to be any(uint(2)) at runtime.
  - aatd86 1y ago
    Not sure that reflection would be needed. They are exclusively on the RHS. But you're right. They would have a sort of type of their own instead of basically being int under the hood. type conversions do not require reflection. Or maybe you are thinking about something I have overlooked? In any case, not very likely a change anyway.
    - kbolino 1y ago
      Let's assume the runtime representation case, as it's the most flexible. You'd need to do an assignability check to compare it to a typed number. Keep LHS as the interface, and RHS as the untyped constant. That means following the type pointer of LHS, switching on its underlying type (with 15 valid possibilities [1]) or similar, and then casting either RHS to LHS's type, or LHS to the untyped representation, and finally doing the equality check. Something like this (modulo choice of representation and possible optimizations): import ("math/big"; "reflect") type untypedInt struct { i *big.Int } func (x untypedInt) equals(y any) bool { val := reflect.ValueOf(y) if val.Type() == reflect.TypeOf(x) { return x.i.Cmp(val.Interface().(untypedInt).i) == 0 } else if val.CanInt() { if !x.i.IsInt64() { return false } return x.i.Int64() == val.Int() } else if val.CanUint() { if !x.i.IsUint64() { return false } return x.i.Uint64() == val.Uint() } else { var yf float64 if val.CanFloat() { yf = val.Float() } else if val.CanComplex() { yc := val.Complex() if imag(yc) != 0 { return false } yf = real(yc) } else { return false } xf, acc := x.i.Float64() if acc != big.Exact { return false } return xf == yf } } [1]: Untyped integer constants can be compared with any of uint8..uint64, int8..int64, int, uint, uintptr, float32, float64, complex64, or complex128
      - aatd86 1y ago
        If it is because of overflow, the idea was that there could be size classes at compile time. A bit like sub/supertyping but for numeric types. A simple type pointer check would be sufficient.
        kbolino 1y ago
        Size classes would save some space and speed up like-to-like comparisons, but wouldn't really do much for unlike comparisons (especially vs. float or complex). Looking only at type pointers fails to account for custom types (e.g., type Foo int); remember that an untyped integer constant can be compared with these. If you want the same semantics at runtime as you get at compile time, I don't see how you can get much simpler than what I wrote, in terms of the high-level logic. Though there are undoubtedly ways to optimize it, both because Go's compiler favors speed of compilation over efficiency of generated code, and because if this were the real code, it could poke at internals while my (probably working) example has to rely on the public reflect package, which is more abstract.

aatd86 1y ago

that's another thing that makes it difficult to fix. Same thing here. 2 is an untyped constant so it should have returned true. (even if int is the default picked on short assignment) any(uint(2)) == int(2) should return false indeed however.

kbolino 1y ago
Untyped constants deserve an entry of their own in a list of the language's subtleties, that's for sure. Importantly, untyped constants don't exist at runtime, and non-primitive types like interfaces aren't constants, so any(uint(2)) == 2 can't behave the way you want without some pretty significant changes to the language's semantics. Either untyped constants would have to get a runtime representation--and equality comparisons would have to introduce some heavyweight reflection--or else interfaces would have to be hoisted into the constant part of the language--which is quite tricky to get right--and then you just end up in a situation where any(uint(2)) == 2 works but x == 2 doesn't when x turns out to be any(uint(2)) at runtime.
- aatd86 1y ago
  Not sure that reflection would be needed. They are exclusively on the RHS. But you're right. They would have a sort of type of their own instead of basically being int under the hood. type conversions do not require reflection. Or maybe you are thinking about something I have overlooked? In any case, not very likely a change anyway.
  - kbolino 1y ago
    Let's assume the runtime representation case, as it's the most flexible. You'd need to do an assignability check to compare it to a typed number. Keep LHS as the interface, and RHS as the untyped constant. That means following the type pointer of LHS, switching on its underlying type (with 15 valid possibilities [1]) or similar, and then casting either RHS to LHS's type, or LHS to the untyped representation, and finally doing the equality check. Something like this (modulo choice of representation and possible optimizations): import ("math/big"; "reflect") type untypedInt struct { i *big.Int } func (x untypedInt) equals(y any) bool { val := reflect.ValueOf(y) if val.Type() == reflect.TypeOf(x) { return x.i.Cmp(val.Interface().(untypedInt).i) == 0 } else if val.CanInt() { if !x.i.IsInt64() { return false } return x.i.Int64() == val.Int() } else if val.CanUint() { if !x.i.IsUint64() { return false } return x.i.Uint64() == val.Uint() } else { var yf float64 if val.CanFloat() { yf = val.Float() } else if val.CanComplex() { yc := val.Complex() if imag(yc) != 0 { return false } yf = real(yc) } else { return false } xf, acc := x.i.Float64() if acc != big.Exact { return false } return xf == yf } } [1]: Untyped integer constants can be compared with any of uint8..uint64, int8..int64, int, uint, uintptr, float32, float64, complex64, or complex128
    - aatd86 1y ago
      If it is because of overflow, the idea was that there could be size classes at compile time. A bit like sub/supertyping but for numeric types. A simple type pointer check would be sufficient.
      - kbolino 1y ago
        Size classes would save some space and speed up like-to-like comparisons, but wouldn't really do much for unlike comparisons (especially vs. float or complex). Looking only at type pointers fails to account for custom types (e.g., type Foo int); remember that an untyped integer constant can be compared with these. If you want the same semantics at runtime as you get at compile time, I don't see how you can get much simpler than what I wrote, in terms of the high-level logic. Though there are undoubtedly ways to optimize it, both because Go's compiler favors speed of compilation over efficiency of generated code, and because if this were the real code, it could poke at internals while my (probably working) example has to rely on the public reflect package, which is more abstract.