Hello, may I add Pair.swap(), Pair.sort(), Triple....

# kontributors

[Tomasz Krakowiak]

Hello, may I add Pair.swap(), Pair.sort(), Triple.sort() to stdlib? ^^

[elizarov]

Why would you need them? What are the use-cases?

[Tomasz Krakowiak]

Plenty of applications in algorithmic and data structures. At least for pairs. Personnaly I just used Pair.sort() for MutableList<T>.swapRanges()

private fun <T> MutableList<T>.swapRanges(aRange: IntRange, bRange: IntRange) {
    val (firstRange, lastRange) = (aRange to bRange).sort { a, b -> a.first.compareTo(b.first) }
    val firstRegionView = subList(firstRange.first, firstRange.last + 1)
    val firstRegionCopy = ArrayList(firstRegionView)
    val secondRegionView = subList(lastRange.first, lastRange.last + 1)
    val secondRegionCopy = ArrayList(secondRegionView)
    firstRegionView.clear()
    secondRegionView.clear()
    firstRegionView.addAll(secondRegionCopy)
    secondRegionView.addAll(firstRegionCopy)
}

Pair.swap() I use in Pair.sort()

private fun <T> Pair<T, T>.sort(comparator: Comparator<T>) : Pair<T,T> {
    val compare = comparator.compare(first, second)
    return if(compare <= 0) {
        this
    } else {
        this.swap()
    }
}

We can also use Pairs to represent non-directional graphs edges and normalize them using sort to represent 2 element nodes set.

I encountered quite a few cases when I wanted to sort Pair's. If you're developer I guess you can imagine quite a lot of use-cases as well : ) But in general Pairs and Triples and other tuples can often be used as efficient fixed size collection/list implementations.

[elizarov]

Algorithms usually care about speed, so using pairs may not be appropriate for them anyway. As for graphs and other similar things I would not recommend using pairs for another reason. Defining a domain-specific data class (even if that is just two fields) works much better in many respects.

[Tomasz Krakowiak]

@elizarov Agree, but you can impelement edge as inline Pair and simplify implementation a bit in some cases.

[Zhelenskiy]

Implementing List<T> interface for tuples of the one type as described in KT-45587 (Tuples (structural literals and structural types) by me would make such functions (Pair.sorted()) possible.

[Tomasz Krakowiak]

Yay! Implement all Ceylon features ^^

[elizarov]

We don't currently plan to unify tuples and collection types in Ceylon-style as the effort of doing so does not seem to be justified by the pragmatic benefits it brings (Ceylon kind of proved that). So far, we are looking at list literals (which contain a variable number of items of the same type) and at tuples (which contain a fixed number of items of different types) as two separate, albeit related, features.

[Zhelenskiy]

If so, what discussion is mentioned (by me) issue for?

[elizarov]

That is an issue for tuples. A tuple is an ordered sequence of elements, each having a different type, so, in general, an operation to sort a tuple (or to have it implement a List interface) does not make much sense.

[Zhelenskiy]

Ok, but there are other operations suggested (concatinating, getting by name if it is named). I hope they are going to be supported.

[elizarov]

Having named tuple for Kotlin is of utmost importance, indeed. It quickly becomes needed at industrial scale. We might even start with only supporting named tuple, since anonymous tuples often and quickly lead to unreadable code.

[elizarov]

Tuples in Kotlin are easy to grasp conceptually — they are just anonymous data classes to which we might add few tweaks here and there

[Zhelenskiy]

I absolutely agree about unnamed tuples as I saw the result of the bad usage in Haskell code