I'm pretty worried that the Java ecosystem is just going to start throwing Optional everywhere instead of using nullability annotations and create yet another hard to optimise source of general sluggishness

Java has that problem too much already. if Optional was a value type it wouldn't be soooo bad, it'd just be verbose.

but pre-valhalla, Optional is a perf problem too

Create your own Maybe types, customize w/ whatever higher-order functionality you need, and keep it trim and flat. Voila! Maybe, Either, Result etc. are pretty easy to implement if you need that functionality, so it's no great loss in the end if Optional is crappy. Just makes it frustrating that that's all we got when we could have gotten so much more. Optional makes sense at module boundaries, but isn't necessarily as useful internally. In the end, we simply need a smoother way to represent 'absence of value' in a typesafe way, and Optional doesn't quite cut it. When was the last time you actually needed null to be a valid 'present' value, and thus couldn't wrap it in an Optional? (rare, but possible occurrence)

The other caveat, I suppose, is that by all accounts we can treat this is a classic 'Special Case' pattern. The absence of value is handled differently for each type, and can even contain its own behaviour. So the general-purpose constructs such as Maybe only end up being practical for highly anemic types, such as pure data types.

Ok so it's a performance issue first and foremost? And of cause it's better in kotlin where nullable is part of the language. But I would probably add filter and map/flatmap as extension functions to Any?. Do you see that as a problem? ('.?' is not really map)

I don't agree that a custom NullObject is mostly preferable. I would use a NullObject in cases where the object has a reasonable 'null value' like a salery would be 0. But in many cases the behavior in the null case is context dependent. For example if a customer email is absent do we then use the empty "" email, filter it out, or send it to the company email

Is there something like this in stdlib:

kotlin
/**
 * Intersperses element [separator] between the elements of the list.
 */
fun <E> List<E>.intersperse(separator: E): List<E> {
    if (this.size < 2) {
        return this
    }
    val result = ArrayList<E>(this.size * 2 - 1)
    this.forEachIndexed { i, e ->
        if (i > 0) result.add(separator)
        result.add(e)
    }
    return result
}

I was thinking some version of

joinTo

but that only works for

Appendable

listOf("a", "b", "c").flatMap { listOf(it, "|") }.dropLast(1)

works but is not very efficient

@kirillrakhman: nice, my first stab was exactly that, flatMap followed by dropLast

do we have anything like this in the stdlib? Not sure how useful it is, I just needed it for something I was doing though

/**
 * Splits the receiver iterable into sublists, where a new sublist is started with every element
 * that returns true when [splitPredicate] is tested against it.
 */
fun <T> Iterable<T>.splitWhen(
        splitPredicate: (index: Int, element: T, currentSubList: List<T>) -> Boolean
): List<List<T>> {
    val result = mutableListOf<MutableList<T>>()
    forEachIndexed { index, element ->
        if (index == 0 || splitPredicate(index, element, result.last())) {
            result.add(mutableListOf<T>())
        }
        result.last().add(element)
    }
    return result
}

(usage examples here: http://try.kotlinlang.org/#/UserProjects/289m71do9v1t5lipd0cd9cvrne/m22tsctvfmbinkggl8k73g7htu)

@kevinmost: We're going to provide something like

window

function (https://youtrack.jetbrains.com/issue/KT-10021) for usages covered by

splitEvery

in your proposal.

Looks useful, thanks!

There seems to be no extension method for

MutableList

that combines

firstOrNull

and

remove

. Would you find something like that useful:

val removed : T? = list.removeFirst { it.predicate() }

here's my proposal: https://youtrack.jetbrains.com/issue/KT-11953

@kirillrakhman: would be a good idea to have a removeFirst that throws a NoSuchElementException and a removeFirstOrNull that returns T?

probably, as it would be in line with the other stdlib extension methods

you should add that as a comment to the issue

added as a comment, I hope they accept them simple smile

the second implementation is probably good enough for

MutableList

, too. It's not a lot less efficient, since

indexOfFirst

needs to allocate an

IntRange

, too

I agree, in the worst case it's O(n) and I think that it's acceptable for a function of this kind

and iterating with Iterator is probably the most efficient way in Java to iterate lists

not if it's

RandomAccess

then index based is faster

didn't know that :O

well, you don't have to allocate an iterator

no allocations is better than some allocations and since it's array backed, indexed access is O(1)

👍 but is there any way to know if a list is RandomAccess? Now

public fun <T> mutableListOf(vararg elements: T): MutableList<T>

returns an ArrayList, but because I'm looking at the source code