someday I'll need to read up about all this invokedynamic stuff.

my current understanding is that it's a magic solution to potentially everything in the JVM

that said, you are right ilya that there is an assumption the code operates on a fixed number of parts, even if the total size may not be clear up front

i guess my main concern/thought is that stdlib methods that abbreviate code by only a tiny amount should probably be things that you use all the time. map/filter/forEach/etc are all like this

pre-sized StringBuilders are usually an optimisation and that's not something you see every few lines

hi, i am searching a function to round an double or float value with a specific count of numbers (e.g. 1.23456 should be rounded to 1.235). is there a function in any standard library of kotlin (i did not found any)?

normally such rounding is done only when you convert the number to a string, which can be accomplished using

String.format

@mikehearn: could you show an example of

buildString

you're arguing about?

it was just added to the 1.1 stdlib, no?

@mikehearn: So you're talking about recently added

buildString

overload with the initialCapacity parameter and not that overload without it?

@mikehearn: if yes, than let's move the discussion to the PR it was originated from: https://github.com/JetBrains/kotlin/pull/893. If we find compelling arguments not to include it, we may reconsider the decision and rollback it.

Generally it's the same reason because of which there's no

HashSet.filter(): HashSet

or

Queue.filter(): Queue

. We hadn't found enough reasons to duplicate all available collection operations for every possible

Collection

inheritor just to preserve type of the returned collection.

@bodo you can easily add your own extensions to the numeric type of your choosing. I've done that (as well as some others like boolean.enabledString() to give a "enabled" or "disabled" conveniently. But such things probably are not useful outside of select areas. No need to add to stdlib probably

@ilya.gorbunov: why not create a generic method like

inline fun <reified T: Iterable<R>, R> T.filter(predicate: (R) -> Boolean): T {

?

filter

could easily be replaced by a generic method, not sure about

map

then how are you going to construct a new T? it's not guaranteed that it's a common collection or that it has a parameterless constructor

yes, it'd require type constraints so you could require the type to have a parameterless constructor

it's a feature request that's popped up before

c++ has quite an advanced notion of 'concepts'

what if you call it on an interface like

Set

?

I've never seen a convincing proposal for this kind of thing compared to simply requiring a factory,

() -> T

did anyone come across a strangest thing: I just can't figure out why

list.flatMap()

processes only a first element of this list (checked in debugger, plus logging). I just replaced

flatMap

with

for..in

+ manual accumulation and it started to work.

Can you post some example code?

not at the moment, too busy. I also suspect it would be hard to isolate/reproduce in a minimal example. perhaps some bug in incremental compilation or something like this. I asked because someone might already run into this. really weird.

bugs in stdlib functions? I doubt that. Post the example ASAP, here or on SO

I doubt that too, that's why i used terms "strangest" and "weird" 🙂

@dimsuz: don't you have return in lambda?

now that I think of it, I might have had it. But I already refactored that code, no way to check. Maybe will try to refactor it back to flatMap later, thanks for pointer.

@dimsuz: This thing with

flatMap

sounds strange, indeed. Does the

transform

function argument in

flatMap()

has side-effects, or does the

Iterable

or

Sequence

where it is called on make any special things?

no, it didn't have any of that. it was simply mapping over list to produce another list. But I might have put there some

return

stuff out of java-habit though I'm not sure I would. I'll have to check in later. I was in the rush to get things done, so refactored that code to a simple

for..in

Intelij has a build in history of changes, should be no problem to look it up