Add slices reduce functions

[Sypheos]

What does this PR do?

Add reduce function from zero or with base

What are the observable changes?

Sum helper

Good PR checklist

• Title makes sense
• Is against the correct branch
• Only addresses one issue
• Properly assigned
• Added/updated tests
• Added/updated documentation
• Properly labeled

[AlexisMontagne]

Suggested change

	func Sum[T sumable](i, j T) T {
	func Sum[T sumable](vs ...T) T {

you could generalize it

[DarkMiMolle]

Suggested change

	func Sum[T sumable](i, j T) T {
	func Sum[T sumable](values ...T) T {

[Sypheos]

That won't compile unless the reduce function accepts variadic args too, which kind of defeats the purpose of a reduce.

We could change things up and have Sum call Reduce which will provides a function link sum := slices.Sum(numbers)

[AlexisMontagne]

im skeptical of the With, it does not evoke anything to me, wdyt of ReduceFrom or ReduceWithInitial

[xgoffin]

Eh, as said, I'm not big on this change. I think reductions not only damage code readability, but that in the cases where they need to happen, they can be made on a case-by-case basis without having to have a custom func for that. It's definitely a part of ruby I'm glad we don't have in go, so I don't really wanna bring it in ourselves 😅

[xgoffin]

ReduceWithAggregator?

Also is this not possible?

Suggested change

	func ReduceWith[S ~[]E, E any, A any](s S, acc A, fn func(A, E) A) A {
	func ReduceWith[E any, A any](s []E, acc A, fn func(A, E) A) A {

Not sure if the compiler'll like it

[xgoffin]

Also naming the vars something a bit more explicit can be useful

• s => elements
• acc => accumulator
• fn => transformationFunc
  Or something? Otherwise we're really sending a telegram like we do in ruby

[AlexisMontagne]

what @Sypheos wrote is pretty standard, it allows typedef of slices to be accepted as paramenter,

for some reason you'd like:

type Strings []string

you could pass directly a value of type Strings as first param

[DarkMiMolle]

• s => elements
• acc => accumulator
• fn => transformationFunc

I would go with something like:

• s => slice
• acc could stay the same, it is a pretty standard name for accumulators
• fn => reduceFunc

[xgoffin]

Honestly at this point, the heavy part of the API, to me, is the generic types. I think we can consider that the devs can pass the zero-value as accumulator themselves, don't you think? 🙂

[Sypheos]

Both approaches are valid. We chose to have two functions to be more explicit, as opposed to Ruby, and avoid having to type out empty strut types.

[xgoffin]

Will that not cause an issue? The fact that we have a private constraint on a publicly exposed func?

[Sypheos]

It won't bother the compiler since it is used as a constraint not as a value.

[Sypheos]

Eh, as said, I'm not big on this change. I think reductions not only damage code readability, but that in the cases where they need to happen, they can be made on a case-by-case basis without having to have a custom func for that. It's definitely a part of ruby I'm glad we don't have in go, so I don't really wanna bring it in ourselves 😅

We thought about using this helper in the PRs last sprint. It could actually have saved us some time, lines of code and believe it or not readability. We are not taking this out of Ruby but out of the Functional Programming book which IMO is a good thing.
If you think back, the same argument could have been done for the Map functions but I believe everyone is quite like it now. We also have the compiler and type enforcing in go that should avoid pondering what the output of the reduce and what signature to use.