proposal: math: Reflect, Least, Greatest

[jimmyfrasche]

package math

func Reflect[T Number]() Kind
type Kind uint
func (Kind) Size() int
func (Kind) Ordered() bool
func (Kind) Float() bool
func (Kind) Complex() bool
func (Kind) Signed() bool
func (Kind) Unsigned() bool
func (Kind) Integer() bool

func Least[T Ordered]() T
func Greatest[T Ordered]() T

func Convert[S, T Number](T) (S, bool)

Reflect returns a Kind bitset that provides information about the properties of a numeric type. The bool returning methods correspond with the constraints and Size returns 8, 16, etc. Since this is about the properties of the type not its identity Reflect[int]() == Reflect[int64]() on platforms where int is 64 bits.

Least (Greatest) return the element that is <= (>=) every element in T. For example, Greatest[float64]() is math.Inf(0), Least[uint]() is 0, and Greatest[int16] is math.MaxInt16.

Convert performs the conversion between numeric types S and T and the boolean reports whether the conversion was lossless, returning false if there was any truncation or wrapping.

Future versions of the language may allow Reflect to be written using type switches but this would still provide a more convenient interface.

---

For convenience, I've assumed #52427 is accepted and that Unsigned, Signed, Integer, Float, and Complex have been moved into package math.

I have also assumed that these additional constraints are defined:

type Ordered Integer | Float
type Number Ordered | Complex

The Ordered constraint is similar to that in package cmp except that it does not include ~string. The package qualification should be sufficient to disambiguate.

If this api is too much or too different for math, it, and all the constraints, could go into a new package, math/number or the like.

[fzipp]

It's possible to get this information with real reflect but that is heavyweight.

Why would this one be less heavyweight? What would it do differently?

[jimmyfrasche]

Unlike reflect.Type, math.Type would only have finitely many values. With language support the body would probably look something like:

switch T.(type) {
case ~uint8:
  return uint8Type

Even if it needs to resort to skullduggery and reach-into-the-runtime or teach-the-compiler-a-trick magic to work around the current inability to write that in Go itself, I'd imagine that it would still retain the essence of being a simple lookup.

[earthboundkid]

At this point, math contains almost all float64 stuff. I think if there's a package with generic math stuff, it should go in a new package, and the old math package can be considered implicitly "math/float64s". Maybe math/numeric.Types/Reflect()/Min()/Max().

[jimmyfrasche]

If it needs a new package, that's fine by me. math does already have untyped constants for all the Min/Max values, though.

[zephyrtronium]

I created https://github.com/zephyrtronium/number as a demonstration of the proposed Reflect function. It does perform faster than reflection, but unless there is some reason to believe the layout of internal/abi.Type will change in the future, I don't think it needs to be in the standard library.

[jimmyfrasche]

First, super cool!

Second, I do think even if the abi remains stable I'd feel uneasy relying on a third party dep making those kind of assumptions and playing those kinds of shenanigans.

Third, I think regardless of implementation having it part of the stdlib is worthwhile to have it in a centralized place, especially one that can be updated in lockstep if something like, for example 128 bit ints get added to the language.

[jimmyfrasche]

Here's a small example of use. It provides a fully correct generic variadic min. It works correctly even if len(vs) == 0 and uses math.Min instead of < for floating point types:

func Min[T notComplex](vs ...T) T {
  min := math.Greatest[T]()
  
  if math.Reflect[T]().Float() {
    // T = ~float32 | ~float64
    // so these are always lossless conversions
    min := float64(min)
    for _, v := range vs {
      min = math.Min(min, float64(v))
    }
    return T(min)
  }
  
  for _, v := range vs {
    if v < min {
      min = v
    }
  }
  return min
}

[fzipp]

With language support the body would probably look something like:

switch T.(type) {
case ~uint8:
  return uint8Type

You can't switch on a generic type like that. If you're proposing a language change ("With language support ...") you should say so.

[jimmyfrasche]

@fzipp I was saying that IF there were such a language change the code would, then, in that hypothetical scenario, just be a big ole switch.

[jimmyfrasche]

@zephyrtronium a more concrete argument against relying on the internals is that alternate Go implementations may not use the same representation internally but if it's in std each such implementation can wire it in appropriately.