I wonder if Kotlin will have sumBy and sum for List<BigDecimal> in the future? Useful in banking system, and one does not have to write his own:);)

Thxs:)

For now you can use fold. Or create an extension function until it makes it into std Lib.

I know:) And I have this function, but should be a part of Kotlin:);)

I think you'll fine "it should be part of Kotlin" to be a rather controversial statement. Personally, I don't think it should.

Why not? Kotlin stdlib has a separated package for JVM-specific collections and predefined set of overloaded `operator`s to work with Java Big*s. Also, summing a lot of those is quite an operation, which is better be written and optimized once and for all

I don't think there's any optimization to be done on

.fold(BigInteger.ZERO, BigInteger::add)

Than why is it part of stdlib for double, byte, int?:)

@karelpeeters the problem I thought might be that you create a new object of

BigInteger

every time (because you do), but that's exactly what's not an issue, I've discovered yesterday

.fold(BigInteger.ZERO, BigInteger::add)

Why not

.reduce(BigInteger::add)

? 😛

@Egor Trutenko Yeah you'll have to create one anyway, they're immutable.

@karelpeeters ikr. You might avoid creating new BigIntegers if you operate on bytearrays. This way, you'll have only one instance of a bytearray, which will in the end of operations be converted to resulting BigInteger, for example. But again - it's not worth a try, Big*s in Java are insanely fast, even though you'll create 10000 instances of BigInteger just to sum 10000 input BigIntegers

Turns out you can get better performance with reflection: https://stackoverflow.com/questions/7863023/java-mutable-biginteger-class, of course that's still a bad idea.