4 ms·

But the LHS can determine how it compares to the RHS when the RHS is determined to be an untyped constant? Or instead of saying RHS (my mistake), let's say the

• kbolino 1y ago
  Ok, I think I follow. Instead of putting the comparison logic on the untyped side, you'd put it on the typed side. In code, reusing imports and untypedInt declaration, but replacing the method from before, you'd have: type intType interface { ~int | ~int8 | ~int16 | ~int32 | ~int64 } func equals[I intType](x I, y any) bool { switch val := y.(type) { case I: return x == val case untypedInt: return val.i.IsInt64() && val.i.Int64() == int64(x) default: return false } } And this would need a separate specialization for unsigned integers, floats, and complex numbers. This approach saves us from having to introspect the underlying type at runtime, but the example is incomplete. We also have float and complex untyped constants, so now each concrete type has to switch on all of the untyped constant forms it compares with. Still, it might be faster, though I'm not sure how much it reduces code bloat in practice (it's nice to not need the reflect package though). [edit: side note, I was trying to actually write out all the code that would be needed, and I discovered that you can't call real or imag on generic types: https://github.com/golang/go/issues/50937 https://github.com/golang/go/issues/50937]