remove golang.org/x/exp since it doesn't follow go 1 compatibility promise

[trim21]

document says golang.org/x/exp doesn't follow go 1 compatibility promise, so copy the package we used to internal for future compatibility promise.

In the future if downsteam user import exp with a newer non-compatibility version it will get unexpected surprise.

[samber]

Good to know. Thanks for the contrib!

[andig]

If I were using constraints I'd be aware of them being an experimental Go feature and I'd expect libraries to follow the current /exp version. I could then also chose the /exp version I want via replace directives in go.mod. With this PR I can no longer do so.

[samber]

The constraint defines interfaces. These interfaces are the responsibility of the receiver, not the caller.

Can you explain why you would replace the exp version?

[andig]

Can you explain why you would replace the exp version?

Why would you cast it in stone?

The point of fixing the exp version in this PR is to maintain it's current state. If I want to use a newer exp version (maybe more options for comparable, say complex numbers, whatever) I can no longer do so.
Making this change- since lo doesn't care what comparable exactly is as long as the compiler guarantees that it is- this change is imho restricting flexibility without adding any gain.

[trim21]

The point of fixing the exp version in this PR is to maintain it's current state. If I want to use a newer exp version (maybe more options for comparable, say complex numbers, whatever) I can no longer do so. Making this change- since lo doesn't care what comparable exactly is as long as the compiler guarantees that it is- this change is imho restricting flexibility without adding any gain.

I understand your point.

comparable is defined by go builtin (compiler itself), not exp, so we don't need to update it.

exp define constraints.Ordered, but internal/constraints will use cmp.Ordered when it's available, for example, go>=1.21 . And docs says golang will update cmp.Ordered if there are new ordered type in the future.

https://github.com/samber/lo/pull/478/files#diff-e643bcba3f902989d454c97e2acc5e86b65b34f330490195c9570a408dfe58f7

IMO the potential issue is, go may add more addable type, constraints.Float | constraints.Integer | constraints.Complex, for example int128 like complex128. Only in this case we need to update our internal/constraints

lo/math.go

Line 70 in f30fce5

func Sum[T constraints.Float | constraints.Integer | constraints.Complex](collection []T) T {

sadly do doesn't have a "Addable" type, this is a real issue.

And the problem with exp is, it doesn't have compatibility promise and go mod doesn't allow library to set a max version boundary, so there is no way lo know if a exp version works with lo itself of not.