OOC, what's the reasoning for extensions existing for some primitives, but not others? For example,

Iterable<T>

has

sumBy

(

Int

) and

sumByDouble

, but no

sumByFloat

. These seem like odd omissions

probably because floats are generally terrible datatypes to use unless you have no other choice.

That's fair. It is an Android consideration though, since nearly all the APIs use floats instead of doubles, so there are some big use cases

why is

getRaw

now deprecated?

@kirillrakhman:

get

can be used instead in the most cases, and

get

with casting parameter to Any in the rest.

Is this intentional, Kotlin SNAPSHOT build that the signature of

with

has changed? was in all previous versions (BETA 4 and before):

public inline fun <T> T.with(initWith: T.() -> Unit): T { … }

now in SNAPSHOT is:

public inline fun <T, R> with(receiver: T, f: (T) -> R): R {  … }

EDIT, is my bad, repackaging of things changed what was imported at the moment when using SNAPSHOT vs. BETA 4

@apatrida:

with

function signature haven't been changed for more than a year, you can check our sources: https://github.com/JetBrains/kotlin/blame/beta4/libraries/stdlib/src/kotlin/util/Standard.kt#L37

maybe is a problem with BETA 4 plugin, but viewing SNAPSHOT version of lib

The former function you have mentioned is not from stdlib.

ah, I see what happened, package changes, it picked up my extension instead of original with

with hadn't been moved, it's still in

kotlin

package

hmmm

either way, the extension function changed to have higher priority to the compiler than the other function. without a code change

see last comment in https://youtrack.jetbrains.com/issue/KT-10492

SHOULD both

with

top level and

T.with

be able to coexist? @ilya.gorbunov

regardless, some change happened, not sure if intentional.

I found a strange method in stdlib:

public fun <T : Any> Iterable<T?>.requireNoNulls(): Iterable<T> {
    for (element in this) {
        if (element == null) {
            throw IllegalArgumentException("null element found in $this.")
        }
    }
    return this as Iterable<T>
}

As far as I understand after invoking this method the iterable may become empty.

It doesn't remove elements, it just checks whether there are no null values. Exception otherwise.

Still, it does look like it's returning an iterator pointing behind the last element, I think the question is legitimate simple smile

it's returning an Iterable, not an Iterator

this

is

Iteratable<T?>

I think it should return

List<T>

instead and make a snapshot, like all other functions on

Iterable

, e.g.

filterNotNull

same function on

Sequence

should be lazy of course. /cc @ilya.gorbunov

Even if the original receiver is not a

List

?

Yep, Iterable operations are always snapshots, to avoid capturing lambda’s closures, having view instead of snapshot, etc. We’ve seen too many issues with that in C#. When you need performance and/or lazy eval, you can always explicitly convert to sequence.

with

asSequence()

I think it should always return the original type but I’m not sure if that’s possible (don’t think so), but I guess I would like something as (next signature has it’s problems):

public fun <T : Any, S : Iterable<T?>, R : Iterable<T>> S.requireNoNulls(): R

@mplatvoet: It’s possible but it leads to

CanBuildFrom

which Scala is still trying to recover from today. Really not worth it, agree with @orangy

Java does the same thing, end up in a collector and drop the elements in a specific container manually if you want to (most of the time, you just don’t care and

List

is fine)

yes I wouldn’t opt for the scala way either