This has come up before, though without a definite answer. See #52427, which was closed with the suggestion to open a proposal specifically for this purpose. If I remember right, one of the main hesitations of doing this would be that packages that didn't need any other functionality from the math package would have to depend on it just to get access to the constraints. Probably not a huge problem, though, since the linker can probably just discard the unused rest of the package.

Separately, I think that I'd want Integer broken into two groups, Signed and Unsigned:

type Signed interface {
  ~int | ~int8 | ~int16 | ~int32 | ~int64
}

type Unsigned interface {
  ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr
}

type Integer interface {
  Signed | Unsigned
}

If the issue was importing whole package because of these interfaces, then what about creating math/constraints package?

And regarding Signed and Unsigned interfaces... that also can be useful. I just thought that these other interfaces were more important. But we don't lose anything by adding those two types that someone can use.

There's also #60274 that is for adding some helpers to math but notes that it could go in a package under math and if so that package would be a good place for the constraints.

@djordje200179

If the issue was importing whole package because of these interfaces, then what about creating math/constraints package?

As mentioned in #52547, if #57644 happens, then "constraints" is a bad package name regardless of path.

@djordje200179 Can you please give some (ideally real-world) examples of how and where this would be used?

@djordje200179 Can you please give some (ideally real-world) examples of how and where this would be used?

1. All math calculation could be made generic, and not only for float64 (like previously done with functions in math package). Many of them couldn't accept Number as parameter, but they could accept Float or Integer, and not enforce float64/int.

2. Numpy-like and scipy-like matrixes and calculations for any type (generic matrix with addition/scalar product/dot product, transpose, negations).

3. Data sources for charts, graphs, histograms..., and other statistics-related stuff.

4. If proposal for iterators becomes reality, then we could have function that creates a range within limits and with given increment
   for i := range Increment(2, 10, 2) { ... }

Those things were first ones that came to my mind, but there are probably a lot more things that could be done.

Our experiences with x/exp/constraints was that approximately nobody used most of the constraints. So I suggest that we focus first on APIs that might want to use these constraints. Then if we those APIs prove popular, we can consider adding the constraints. After all, the constraints might prove to be useful but they are never necessary. We can go from uses to the constraints, rather than from the constraints to uses.

The current math package is pretty much all float64. Only a handful of functions in it even make sense on integers. On a quick scan, the only ones I see are Abs, Dim, Pow, and Pow10. It might make more sense to create some new package that focuses on whatever generic integer math needs to be done, and putting constraints there.

The current math package is pretty much all float64. Only a handful of functions in it even make sense on integers. On a quick scan, the only ones I see are Abs, Dim, Pow, and Pow10. It might make more sense to create some new package that focuses on whatever generic integer math needs to be done, and putting constraints there.

In my opinion, it would be okay to make Abs, Pow and Pow10 generic functions. We would avoid unnecessary casts between integer and float types.

Also, other functions wouldn't need to "force" float64 types. Someone that uses float32 type for his purposes after calling math functions needs to downcast returned result from float64 to float32.

Same thing with cmplx package, that "forces" use of complex128.

In my opinion, it would be okay to make Abs, Pow and Pow10 generic functions. We would avoid unnecessary casts between integer and float types.

While I agree with you and think it would be worth the cost, changing the signature of exported functions would break the backward-compatibility promise.

I would like to express my support for generic float in math, because i often work with float32 and it makes the math package un-practicable for my use case.

Also, curios how would it break the backward compatibility promise?
As i understood it, it would expand on the current implementation without taking away, and type inference from arguments should take care of the rest.

I would like to express my support for generic float in math, because i often work with float32 and it makes the math package un-practicable for my use case.

@BieHDC Thank you for your support!

As i understood it, it would expand on the current implementation without taking away, and type inference from arguments should take care of the rest.

I have also thought about same thing, but @mohamedattahri said that changing the signature breaks code. So, I'm not sure now what is the truth.

I have also thought about same thing, but @mohamedattahri said that changing the signature breaks code. So, I'm not sure now what is the truth.

// If this is generic, this becomes an error because it
// would be a usage of an uninstantiated generic
// function.
f := math.Sin

@DeedleFake Thank you for clarification! I have forgot about function type and having variables.