internal: add package internal/float

[smasher164]

Currently, functions that rely on properties of a floating-point number like its sign-bit, nan-checking, and integer representation get duplicated across packages. For instance,

For instance, isFinite, isInf, abs, copysign, float64bits, and float64frombits are defined in both math and runtime.

isNaN itself is defined in math, math/bits, runtime, sort.

I propose that we move the declarations in runtime/float.go to internal/float and reuse them in both math, runtime, and anyplace else.

I assume this hasn't been done already because internal packages didn't exist at the time most of this code was written. In the case of sort, we wanted to remove its dependency on math, but if we end up adopting #33440, sort will need more access to a float64's underlying representation.

[martisch]

How would the IsNaN package then reference IsNaN in internal/float?

If using:

func IsNan(x float64) bool {
	return internalmath.IsNan()
}

This might cause additional inlining budget to be used affecting performance.

IsNaN some others are also so simple that having it defined multiple times to e.g. avoid adding multiple new dependency seems fine.

[smasher164]

This might cause additional inlining budget to be used affecting performance.

This was my concern as well. Unless there's a way to apply a peephole or a rewrite for this that bypasses the inlining budget, this would affect it.

IsNaN some others are also so simple that having it defined multiple times to e.g. avoid adding multiple new dependency seems fine.

I agree that IsNaN on its own is fine being defined multiple times. I'd be happy if just Float64bits and Float64frombits were exposed, since most of these functions can be implemented in terms of it. w.r.t #33440, we can't introduce have sort import unsafe, but all it really needs is the sign bit.

[bcmills]

This might cause additional inlining budget to be used affecting performance.

If so, we should fix the inlining heuristics. Such a trivial forwarding function should be a zero-cost abstraction.

[ianlancetaylor]

If this doesn't affect public API, I don't think this needs to go through the proposal process.

[gopherbot]

Change https://golang.org/cl/293794 mentions this issue: internal/float: consolidate float property-checking functions

[smasher164]

I sent CL 293794 for this. I am not convinced the deduplication is worth the effort unless we know if future that #33440 will be resolved. I was slightly conservative -- there are packages that import math for these functions, where we could strip that import by having them import internal/float.