notEmptyAndAll

, but yeah

anything more intricate like

anyAll

wouldn't be clear at all

will go on with the explicit case then... thanks for input.

any particular reason why there is no

ClosedRange.component1()

and

component2()

?

For lists we have component1..5 declared to destructure up to 5 first elements of a list. An

IntRange

is a

ClosedRange

though not a list, so these components won't clash if we introduce them for

ClosedRange

. However they may confuse user as now two very similar constructions will mean kinda different things.

hm

I can understand that reasoning

I still think the usefulness would outweigh the potential confusion

luckily, I can just declare them myself

fun Boolean.whenTrue(block: () -> Unit): Boolean {
    if (this) block()
    return this
}

fun Boolean.whenFalse(block: () -> Unit): Boolean {
    if (!this) block()
    return this
}

fun main(args: Array<String>) {
    true.whenTrue { println("That's true")     }
        .whenFalse{ println("That isn't true") }
}

@orangy This would work, I thought this would be cool if it were in stdlib, but again, I suppose it's too minor to be adding things like this there.

@roman.belov has left the channel

@debug it doesn’t work for when you want to have it like

val value = condition.whenTrue {1}.whenElse{0}

yes, that's true

@pabl0rg has left the channel

@get:Suppress("") val foo:String = "Hello World" @Suppress("") get

works fine, but

@get:Suppress("") @get:Suppress("") val foo:String = "Hello World"

- error

This annotation is not repeatable

Is is a bug of a feature?

looks like a bug

issue created https://youtrack.jetbrains.com/issue/KT-14392

fun '_'() = 3; _()

works fine, but

fun '$'() = 3; $()

is not valid, is it expected behaviour? for

fun _() = 3

i receive an error

Names _, __, ... reserved

does it mean i shoundn't be able to call methods with names like

__

?

@denis.zharkov ^^

@stepango 1. The first one about

fun '$'() = 3; $()

looks like an issue, but I'm not sure. Please file a report https://youtrack.jetbrains.com/issues Note that if you add a new line after

;

everything works 2. You always can declare it like

fun '_'() = 3

and call it with _ name (again from the next line)

How about adding

Comparator<T>

to

Comparator<in Iterable<T>>

conversion that will make a lexicographical comparator? Example implementation: https://github.com/h0tk3y/kotlin-fun/blob/master/src/main/kotlin/com/github/h0tk3y/kotlinFun/LexComparator.kt This comparator might not be consistent with

equals

, but Java comparator contract allows this.

@denis.zharkov created https://youtrack.jetbrains.com/issue/KT-14456

@ilya.gorbunov see on comparators ^^

@h0tk3y interesting proposal. There are two considerations regarding it: - will it be possible to provide the same API to build

Comparator<Sequence<T>>

or

Comparator<Array<T>>

? - from my experience of implementing comparator transformations like

Comparator<T> -> Comparator<T?>

, extension functions don't fit quite well for that task. Top-level function might be better here. Have you tried to use such function in a fluent scenario? Imagine you have list, which elements are List<T>, and you want to sort its elements, comparing them lexicographically. How would you create comparator in this case?

@ilya.gorbunov as to the second consideration,

sortedWith(comparator)

is suitable here:

listOf(listOf("a"), listOf("b"), listOf("ab")).sortedWith(naturalOrder<String>().lexicographically())

vs

listOf(listOf("a"), listOf("b"), listOf("ab")).sortedWith(lexicographical(naturalOrder()))

The difference is that type inference fails in case of extension function, requiring explicit type argument. Any other possible issues?

will it be possible to provide the same API to build

Comparator<Sequence<T>>

or

Comparator<Array<T>>

?

Seems like there can only be separate functions for

Array

and

Sequence

, because there's no such

R

that

Comparator<in R<T>>

matches them all.

Seems like there can only be separate functions

Yes, and these functions have to be named differently.

The difference is that type inference fails in case of extension function

That's what I've meant, but not only. Type inference issues might be fixed in 1.1, but nevertheless when you build comparator fluently, for example in such an expression:

listOfLists.sortedWith( compareBy { <cursor> } }

you will have the type of

it

in

compareBy

to be

List<T>

, and to change it to

T

, you'll have to add the extension call first, than return back to lambda body. Thus it hurts fluency.

Now I see. Are there any examples of functions in stdlib that were designed with this concern taken into account?

Also, sequences comparison that takes their iterators inside seems a bit strange to me, mostly because of single iteration constrained sequences.