samber
Create a function to convert unindexed iteratee to indexed
Let's say there's an iteratee:
func iteratee(a int) int {
return a + 1
}
Whenever I use functions in lo, it requires me to write another iteratee to wrap it:
slice = lo.Map(slice, func(i int, _ int) int {
return iteratee(i)
})
Well, it's acceptable, but not elegant. If lo could provide a function like this:
func WrapIndex[T any, R any](f func(T) R) func(T, int) R {
return func(t T, _ int) R {
return f(t)
}
}
Then the function could be written in this way:
slice = lo.Map(slice, WrapIndex(iteratee))
It's seldom we use an indexed version iteratee, most of the time we just throw away the index.
However, providing an unindexed version for all functions would be tedious. Instead, providing a wrapper function to throw away the index should be better.
BTW, I don't know whether I used the words 'indexed' and 'unindexed' correctly. Hope you could understand. XD
I would say the same for predicates— that is, with methods like Filter(slice []T, func(T, int) bool), I am far more likely to be using them in situations where I have a func(T) bool; the index is almost always irrelevant, and it's extremely annoying to have to keep writing inline anonymous wrapper funcs.
First of all, I'm very pleased with the functionality provided by lo package. It's great, many kudos to the author and contributors.
Despite the fact, that having an index argument increases the flexibility of functions and makes them truly general-purpose functions, I can share that based on my personal experience of lo package usage I have never ever used index argument. Literally, never. It's always func(item T, _ int) R.
Since the package is on v1.* and needs to maintain backward compatibility, it's quite hard to change it. What I suggest is releasing v2 and changing the default iterate signature from func(item T, index int) R to func(item T) R and creating additional functions like MapI, ForEachI` which will accept functions with iterate. I'm not sure if it needs a separate issue, @samber what do you think? Can you please share your thoughts on that?
UPDATE:
Also, an important example. This signature stops me from using tons of already existing functions like strings.ToUpper, and instead of this simple line of code lo.Map(strs, strings.ToUpper) I need to write this:
lo.Map(strs, func(s string, _ int) string {
return strings.ToUpper(s)
}
At least it makes sense for me to implement some methods like lo.MapNoI in the current v1.* branch which will handle such signatures.
