at least not without prohibitive overhead

listA.zip(listB) { (a, b) -> a.compareTo(b) }.find { it != 0 }

is the best I can come up with.

yeah that's basically what i have now. i was also toying with making them sequences

It does have some boxing though.

It would be amazing if the Sequence stuff would all be inlined, eliminating any overhead and things like boxing too. One can dream...

It cannot be, by definition

Boxing may be, but inlining – how?

Err, couldn't all of the sequence code be compiled down to ordinary for loops?

For iterable yes, for sequence not so much, they are lazy. Even if you compile them to coroutines, it’s still some closures/instances created

There could be some fusion of sequential operations, like merge filter/map into single operation, but it’s quite complicated

Also note, that fusing operations on iterables changes order of operations.

No, by default both kotlinc and JIT can't do loop fusion, because it means changing evaluation order (even for sequences)

I was thinking about cases where you have bunch of chained

map

,

filter

,

find

, ... operations on a locally created sequence that comes from a list. You'd need the sequence-lazyness for early return.

listOf(1,2).filter { a(it) }.map { b(it) }

Here we call a(1), a(2) and then b(1), b(2) If you fuse them, it would be a(1), b(1), a(2), b(2)

Right, but that's on an interable, on a sequence the order of operations would already be the latter, right?

Q: why are

SortedSet<T>

and

TreeSet<T>

defined as internal in kotlin.collections, but declared as the result type of public functions (such as

toSortedSet()

)? This is in Kotlin 1.1.5-1

I filed the iterable comparator thing for future consideration: https://youtrack.jetbrains.com/issue/KT-20690

Hi all, i have seen some discussions about

Closeable.use(block)

being suboptimal regarding multiple closeables at a time. Therfore I have implemented a `CloseableScope`which can add closeables to a

List

like this:

try {
            CloseableScope {
                val noExceptionCloseable1 = NoExceptionCloseable1().autoClose()
                val bodyExceptionCloseable = BodyExceptionCloseable().autoClose()
                val closeExceptionCloseable1 = CloseExceptionCloseable1().autoClose()
                val closeExceptionCloseable2 = CloseExceptionCloseable2().autoClose()
                val noExceptionCloseable2 = NoExceptionCloseable2().autoClose()

                noExceptionCloseable1.doSomething()
                bodyExceptionCloseable.doSomething()
                closeExceptionCloseable1.doSomething()
                closeExceptionCloseable2.doSomething()
                noExceptionCloseable2.doSomething()
            }
        } catch (t: Throwable) {
            println(t)
        }

CloseableScope(block)

opens the scope,

Closeable.autoClose()

adds a

Closeable

to the cleanup list and at the end of the scope, all Closeables on the list are closed. The multi-exception semantics are modelled after java's try-with-ressource

Now multiple questions 🙂 - Would this be worth a pull request? -

Closeable

.use(block) does not follow java's try-with-ressource semantics to add on-close-exceptions to a former exception (

addSuppressed

), but just ignores them. Has this been discussed already? Are there any documented reasons for this difference in behaviour?

And of course the old naming question. Do you have a better idea for the name

CloseableScope

?

There's a library that does somthing very similar to this, using infix functions to make the whole thing more fluent. I can never find it though, for some reason it doesn't really show up on google.

Got it, had to look trough my browsing history to even find it: https://github.com/DemonWav/kotlin-utils/blob/master/readme.md

@karelpeeters Thanks. So i guess `using`could be a nice name 😉

Le me take a look at his implementation. Interestingly the difference to my implementation is, that he does not need a `try`but requires a

finally

block

And also he changed from unary plus operator to

autoClose

Actually not requiring a

finally

might be the better option, it's more difficult to forget your actual

try

.

I am currently porting DemonWav's unit tests to my implementation

My implementation is very much along the lines of what @orangy suggested in the discussion: https://discuss.kotlinlang.org/t/kotlin-needs-try-with-resources/214/2

If you scroll down a bit that's the thread where it actually originated, DemonWav has a comment in there linking to the library.

Here is the proposed solution as a shameless plug (i.e. fork) of DemonWav's project: <https://github.com/uluckas/kotlin-utils> https://github.com/uluckas/s2s-KotlinAutoClose