Can you argue about returning nil instead of zero value (an empty array).

Because if I try to apply the same rule to other helpers, what would be the behavior of SumBy:

func SumBy[T any, R constraints.Float | constraints.Integer | constraints.Complex](collection []T, iteratee func(item T) R) R {
	var sum R = 0
	for _, item := range collection {
		sum = sum   iteratee(item)
	}
	return sum
}

Hi @samber

The behaviour of SumBy wouldn't change at all as iterating over a nil slice is a perfectly valid operation.

Thanks for approving! Just seen there's a bunch of conflicts so will fix ASAP.

Have fixed the conflicts. Regarding arguing why it should be nil, not zero, If I pass a nil slice into a function to remove elements and it was nil and then it comes back as a zero slice that feels semantically wrong. The behaviour of returning nils when that was passed in is also what the stdlib does in the slices package. See https://go.dev/play/p/kC2YOFdslWO

The reason I was inspired to fix this is because a load of my tests were breaking when I started using lo for filtering and mapping slices as our REST API was suddenly returning JSON arrays for fields which were meant to be nulls.

@samber any chance of getting this merged?