Do we already have a proposal for the spaceship op...

# language-proposals

[Fleshgrinder]

Do we already have a proposal for the spaceship operator? <=> would be nice together with a corresponding Ordering Enum.

when (a <=> b) {
    Ordering.Less -> {}
    Ordering.Equal -> {}
    Ordering.Greater -> {}
}

[gildor]

I don’t think that there is a proposal for this
Now it works as standard Java compare function, returns -1, 0, 1

[Fleshgrinder]

That's for the compareTo call and that one we cannot change for interop reasons but if we add some magic to <=> (through our operator overloading machinery) we could coerce the -1, 0, 1 return value from compareTo to the corresponding Ordering Enum. That said, just having <=> as a shorthand for compareTo would already be nice and make Kotlin more expressive imho.

There's more to ordering than we can do with Kotlin/Java but I don't see how this can ever be fixed nicely (e.g. class B : Comparable<A>, Comparable<B>), maybe with union types and some additional manual labor inside the comapreTo function (e.g. class B : Comparable<A | B>).

[Dominaezzz]

Can always have infix function. 😛 when (a spaceship b) { .

[elizarov]

I’d say that’s a very baroque feature. What kind of code you write where that’d be helpful in any way?

[elizarov]

In my mind, if we start discussion on “what kind of new operations we should add to Kotiln” the bit-wise opeartors will win all the other proposals hands down.

[Fleshgrinder]

@elizarov agree 💯

[Fleshgrinder]

@Dominaezzz no need for infix because I can already do a.compareTo(b) what I cannot do is:

when (a.compareTo(b)) {
    < 0 -> "less"
    0 -> "equal"
    > 0 -> "greater"
}

Simply because that's not how our when works. I think this also explains the idea here (and why the Enum is needed).

[Dominaezzz]

What does "bacoque" mean?

[Dominaezzz]

For that you want the compiler to solve SAT. There's an issue for that.

[Dominaezzz]

https://youtrack.jetbrains.com/issue/KT-20943

[Fleshgrinder]

Not sure how this would help here? 🤔

[elizarov]

typo: baroque

[Fleshgrinder]

This works:

val ord = a.compareTo(b)
when {
    ord < 0 -> "less"
    ord == 0 -> "equal"
    else -> "greater"
}

[Dominaezzz]

val ord = a.compareTo(b)
val value = when {
    ord < 0 -> "less"
    ord == 0 -> "equal"
    ord > 0 -> "greater"
}

This doesn't.

[elizarov]

IMHO, support for < 0 and > 0 in when is way more helpful than a spaceship operator.

[Fleshgrinder]

For me the Ordering Enum is actually what I'm interested in more than the operator. The operator would just be an idea on how it can be introduced without harming interop. With it I can write expressive code like shown above. I understand that you're looking at it from an importance point of view but I never gave it any importance, I just inquired if anyone has ever talked about it. There are many, many, many things more important then this but that's why we have issue trackers where we collect ideas and prioritize them, no? 🙂

[elizarov]

Langauge ideas don’t live in isolation. As soon as you add one feature it immediately changes importance of others. Adding a feature to a language is very expensive, so when we look to add any one we must examine all the other features that could cover the same use-cases.

[elizarov]

For example, if we have < 0 and > 0 in when (which is a very generic feature, helping people in may places), then it immediately makes adding Ordering enum way less important to the point of irrelevance.

[Fleshgrinder]

I agree with what you are saying but Ordering goes beyond the simple usage in a when that is exhaustive. I can also use it to restrict arguments (fun f(ord: Ordering)), to create collections (List<Ordering>), and many other things because suddenly the result of a comparison becomes part of the type system. Ideal would obviously be if Java's Comparable would have been defined like this from the start and we'd have it now too but I guess it's part of the bad things we inherit. (But minor, we don't need to discuss this any further.)

[Fleshgrinder]

There are workarounds, obviously, fun <T> f(a: Comparable<T>, b: Comparable<T>) { val ord = a.compareTo(b) } and for the collection case I simply accept a List<Int> and normalize the values returned from compareTo while inserting to -1..1 or I define my own Enum.