[Hakkin]

Huh, I'm glad to see generic Min/Max functions, but the fact that they're built-ins is a little odd to me. I would have expected them to put a generic math library into the stdlib instead. The fact the stdlib math package only works with float64s has always struck me as a poorly thought out decision.

[klodolph]

Making them builtins allows them to work as you’d expect with cases like,

    func clamp(x float64) float64 {
        return max(0, min(1, x))
    }

With ordinary functions, the arguments are assigned types too soon, and you get integer types for 0 and 1 in the above code. In C++ you might make the types explicit:

    template<typename T>
    T clamp(T x) {
        return std::max<T>(0, std::min<T>(1, x));
    }

That’s not meant to be exactly the way you’d write these functions, but just a little bit of sample code to show how the typing is different.

[Hakkin]

That doesn't seem to be true, unless I'm misunderstanding something. https://go.dev/play/p/ymM0tD3aGYg?v=gotip

Obviously these sample functions don't take into account all the intricacies of float min/max functions.

[klodolph]

You can

    const x = min(a, b)

assuming a and b are const.

[onionisafruit]

I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?

[klodolph]

Const are build-time constants, they are not necessarily the same value across all build configurations.

[onionisafruit]

That’s a good point.

[nordsieck]

> I can't think of a use case for that.

It helps to document intent.

Probably not so useful for min, but it can be more useful for more complex functions.

[tjalfi]

The proposal[0] gives a rationale. Using builtin functions lets them be variadic without allocating a slice.

[0] https://github.com/golang/go/issues/59488

[morelisp]

While I suspect open coding may make the optimization a little easier, there's no reason it couldn't optimize out a slice and fixed 2-3 iteration loop with the same result.

The proposal's real conclusion was "the decision cannot be resolved by empirical data or technical arguments."

[tinco]

What sort of use case do you see for non-float64 math operations in a Go application?

[Hakkin]

Well, the obvious ones are of course Min and Max functions, which is resolved with this. Other ones I commonly find myself wanting to use with integers would be math.Abs and math.Pow I guess. Otherwise they are mostly functions useful with floats, so ultimately I understand the logic, though even in that case, it would be nice if they were usable with float32s as well without casting back and forth.

Personally I try to avoid using floats for calculations if I can (unless it's obviously warranted), I've encountered far too many foot guns from using them, though honestly the same can be said about integers in some situations too. I wish there was a package like math/big that was more accessible, I find the current interface for it pretty abysmal.

[tedunangst]

Float32 is pretty popular in graphics.