that way you see where the eager evaluation is taking place

just remembered an article about the way Closure people unificated push/pull streams. It is not exactly that, but may inspire something. Will do a research tomorrow

Quick question: I have always found

filter

ambiguous, have there been discussions to name it more precisely, e.g.

keep

(and maybe

reject

instead of

filterNot

)

Select & reject are often used

Do you mean Ruby's select/reject/collect/inject/detect functions?

at least

filter

is consistent with all the other java libraries including java 8 streams

is it consistent with javascript? (I honestly don’t know)

I understand

filter

is widespread, I just always have a pause to remember if the items matching the filter are being retained or rejected

@ilya.gorbunov: that naming convention originally came from Smalltalk

Alternatives are also

takeWhen

and `dropWhen`:)

These are even clearer, albeit longer

Why does

coerceIn

accept nullable types? This method becomes unusable for real computations because of boxing. Moreover, there’re

coerceAtLeast

and

coerceAtMost

methods, which are very similar to what

coerceIn

does when one of its arguments is

null

.

Any ideas on the question above?

// cc @ilya.gorbunov

Being able to pass nulls you can coerce a number into halfbounded range

Unlike coerceAtLeast, coerceAtMost this can be useful when the boundness isn't known at compile time

I think the boxing argument is a very relevant one

We may provide overloads without boxing

@ilya.gorbunov: It seems to me that cons overwhelm pros in this situation

I think using nulls as bounds is a pretty rare case and one can write something like that:

value = lowerBound?.let { value.coerceAtLeast(it) }
value = upperBound?.let { value.coerceAtMost(it) }

hey guys. so I'm adding some functions to the stdlib, then generating code with kotlin-stdlib-gen. I also added some tests to stdlib/test, and everything works fine when I

mvn test

inside stdlib. However,

mvn install

inside libraries fails the recently added tests because it can't find the newly added functions. Is that expected behaviour? cheers

@gabrielborges: No, it isn't.

Which module is failing?

https://kotlinlang.slack.com/archives/stdlib/p1449930037000225 nvm. rebuilding everything from scratch (again) seems to have fixed the issue. will report back.

it worked. no clue what happened the first few times I tried.

I’m curious why the Iterable extension

take

returns a List, rather than a wrapper Iterable that simply stops at the specified size.

Functions for Iterable are designed to make a snapshot and avoid any lazy operations. E.g. it doesn’t create a View on original collection. If you want this, use Sequence.

got it. I’ll have to see how Sequence compares to jool’s Seq. Thanks!

@orangy could you add these explanations to the api reference somewhere ?

@yole: ^^ we should probably add List/MutableList etc hierarchy and mapping to Interop section