I'm curious to see what the impl with

mapIndexed

would look like if the lists were of different types.

One more possible implementation, looks like more efficient:

fun <A, B, C> List<A>.zip(b: List<B>, c: List<C>): List<Triple<A, B, C>> {
    val length = min(this.size, min(b.size, c.size))
    return List(length) {
        Triple(this[it], b[it], c[it])
    }
}

nice. that would have been what I would have wrote except with a for loop on the index. the initializer lambda is a nice version of that though

and then it becomes

List(length, func)

!

wait no you need the indexing still

if I have a class like this

data class Person(val name: String, val citiesVisited: List<City>)

and

City(val name: String, val population: Int)

how do I create a

Map<City, List<Person>>

with

groupBy

or similar?

given a

List<Person>

@rrva

list.flatMap { person -> it.citiesVisited.map { city -> city to person } }.groupBy { it.first }.mapValues { _, v -> v.map(Pair::second) }

I'm sure there's a better way...

@karelpeeters thanks. I had a similar solution but also had the same feeling

Is is a good solution. O(cities * persons). I don't think you can find better. Maybe by having less steps and by using Sequene.

It's always going to have at least that complexity, since that's the size of the output.

In a mixed Java-Kotlin codebase, do you consider using stdlib functions from Java as traditional 'utils' instead of writing your own?

they are already there, implemented, proved and unit tested. They should make the eventual migration easier, so I was wondering if there is any downside.

Can you give an example?

@Nonnull
    public static <T> Iterable<T> reverseIteration(List<T> list) {
        if (list.isEmpty()) {
            return Collections.emptyList();
        }
        return () -> new Iterator<T>() {
            @Nonnull
            ListIterator<T> innerIterator = list.listIterator(list.size());

            @Override
            public boolean hasNext() {
                return innerIterator.hasPrevious();
            }

            @Override
            public T next() {
                return innerIterator.previous();
            }

            @Override
            public void remove() {
                innerIterator.remove();
            }
        };
    }

Can be replaced by

CollectionsKt.asReversed(list)

or your own function to read a file can be replaced by

FilesKt.readText(new File(fileName), Charset.forName("UTF-8"));

it seems unorthodox but convenient

I don't see big drawbacks though. If for some reason these methods would become unavailable from Java at any point, they could probably mostly be replaced using alternatives such as Apache Commons.

I think it’s good to use them from Java. The only problem, that not all the functions from stdlib available on java side, some of them marked as @InlineOnly, so doesn’t exist on runtime and not available from Java side

all the useful ones are inline only!

i don't really work on a mixed codebase, but when i did i reused Kotlin stdlib functions in Java to reduce potential method count

public inline fun maxOf(a: Int, b: Int): Int {
    return Math.max(a, b)
}

are these slower than just calling

Math.max

directly? are these just syntactic sugar wrappers?

they're

inline

so no, your resulting bytecode is literally equivalent to if you had called

Math.max

Ah i see

thank you!

while

prices.forEach {
    maxProfit = maxOf(maxProfit, it - minPrice)
    minPrice = minOf(minPrice, it)
  }

took 420ms

just wondering where that would be coming from

Might be the

forEach

yeah that's what i am thinking too