Would it be a good idea to have a overloaded map method that accepts a function of type
def map[B](f: (e: A, i: Int) => B)
Basically the i is the index of the element that is under process. I know we can use zipWithIndex but I really can’t afford to iterate the list twice. Will
list.view.zipWithIndex have a better performance?
What’s your though on the above overloaded method?
Overloading is rarely a good idea. That being said, we’re doing it extensively in the new collections library. Adding an extra
map overload would break this scheme (at least if you were to add it at the
Iterable level where it makes sense). The method should really be called
The two extra Views in
.view.zipWithIndex shouldn’t make a big difference (relative to the high overhead and bad locality of
List), but I expect the extra tuple per element will. You should really do some benchmarking if you want to make a case for adding
Note that both versions need to box the
Int argument. Both
Function2 are specialized for
Int but neither one is specialized for
AnyRef, so with the other type being
A <: Any there is no way to use a specialized implementation.
Didn’t quite get the last paragraph!
With a definition like
def map[B](f: (e: A, i: Int) => B) you may expect that the
Int can be an unboxed primitive because you can have a method type
[A](e: A, i: Int): B with an unboxed
Int. I was merely pointing out that, perhaps non-intuitively, the specialized
Function2 can not do this.
The only advantage compared to the tupled definition is that you do not need to wrap the arguments in a
Tuple2. And since
Tuple2 is specialized in the same way as
Function2 it suffers from the same restrictions, so the tupled version still needs the
Integer wrapper in addition to the