But I don’t really agree creating a snapshot is the way to go

I prefer to keep everything as lazy as possible and let the developer decide to create a snapshot if nessecary

For most operations it is really ok, except for Android.

We had benchmarks and difference on small collections is really unimportant, unless you are on critical path (or Android, where all paths are critical simple smile

I can’t disagree with the results of a benchmark but since the std has to cover also the corner cases I think this a bit more important

And I agree keeping state in a closure is also an issue

Any specific ideas how to improve it? Not that we can do it in the time frame we have, but may be some other library…

in a nutshell I like the above method as-is

But in general I’m more in favour of Iterators/Streams above List (/snapshots)

Just use sequences everywhere simple smile

Okay, back to vacation, sorry to disturb you here 🏂

Happy snowboarding

Happy walking you mean 😉

Being buried in snow myself

Its sunny, bright, and the beaches are nice. Santa is in jungle fatigues.

by the way @mplatvoet, lazy isn’t always more performant. depends on the collection size and operation. I think the stdlib should be consistent (snapshots is its favorite model now) and that sequence is your intentional way to be lazy on demand

Performance isn’t my main concern, it’s memory consumption and garbage. Those are the things that matter on Android obviously, but they do also matter on (high performant) server apps. So maybe one improvement could be that it’s crystal clear that a method creates a new snapshot. So for instance prefix all those methods with

to

(

create

?). Just like

toInt()

and

toDouble()

, above could be

toNoNulls

.

Good point that naming convention should provide a clue, as do most of the stdlib methods.

+1

items.filterToList { …}.mapToList {… }

like this?

Yes, that makes a lot of sense to me. That way you can also have that the “regular” counterparts

filter

and

map

etc always do lazy evaluations, so no matter whether something is an

Iterable

or a

Sequence

, it will be consistent behaviour. The behaviour is not dependent on the type of the receiver. That does leave your concern about accidental reevaluations open as commonly seen with naive C# Linq programming. E.g. where some DB query is fired over and over again because someone forgot to create a snapshot of the results. However, I think a consistent API will make it easier to cope (educate) with such issues.

I like being explicit, but I think that's too much. I don't want to have to change each method when I change the data source from List<T> to a Sequence<T> to avoid creating many List instances.

you won’t have to, that’s not what’s being proposed. The idea is following for instance with the

map

function:

//lazy
fun <T, R> Sequence<T>.map(transform: (T) -> R): Sequence<R>
//lazy (for Lists etc…)
fun <T, R> Iterable<T>.map(transform: (T) -> R): Iterable<R>

//snapshot
fun <T, R> Iterable<T>.mapToList(transform: (T) -> R): List<R>

What would be the point of the Sequence type in that case?

It could be removed and everything be done with Iterable

Then you would tie into Java

I guess the javascript backend doesn’t have something like Iterable

Iterable is defined in the kotlin package

in that case @natpryce, good question.

I like the proposal, without any indicator it retains interface (but not the type, because a

List

of some unknown type needs to become a

List

of some known type) … and with indication you know the results.