@voddan: as you like. But it seems to me that in most apps copying collections is not what application does most time, so increasing performance here won't affect performance of entire application significantly

btw, java's

.clone()

is not faster

shouldn't array operations like

reduce

work with indices instead of allocating an iterator?

related: https://youtrack.jetbrains.com/issue/KT-10579

thanks, I wasn't sure if there was a related issue

looks like it happened

click VCS changes and then on to the SHA

reduce was included

perfect!

reducing over a

vararg

parameter is a nice way to generalize a function with two parameters, having the iterator overhead is kinda sad. looking forward to 1.0.1

Though there is already the overhead of having to allocate an array when using

vararg

right

and I just noticed, I can simply replace the

reduce

with a

max

because I was only reducing with

coerceAtLeast

Char toInt return ASCII code and String toInt it's int representation. So: assertEquals("6".toInt(), '6'.toInt()) is not working. I think it is counterintuitive.

I do not agree. I would expect

’6'.toInt()

to return an integer representation of a character and not a string representation of this character parsed to int.

That’s how it works in all languages I’m aware of.

‘6’ is a numeric type. “6” is not.

so you’re asking to the int form of a numeric value.

I think marcinmoskala has fair point. Not that it should yield to the same results but that the naming can be considered confusing. You have this two methods with the same name that do a fundamentally different operation. For that matter it makes sense to me that String.toInt shouldn’t have existed in the first place.

ups

being past 1.0 resolves a lot of discussions on the spot ))

I have few doubts about stdlib

like map +. It is working like upgrade right now.

val m1 = mapOf(1 to 1, 2 to 2) val m2 = mapOf(2 to 1, 3 to 2)

print(m1 + m2)

give print(m1 + m2)

{1=1, 2=1, 3=2}

and