it seems like the

filterIsInstance()

is just acting as a cast here

so you could get away with

pair.filter { it.second != null }.toMap() as Map<String, Double>

I hope that’s what I was looking for

thanks

Either unsafe or not very efficient

what do you suggest?

pairs.mapNotNull { it.takeIf { it.second != null }?.let { it as Pair<String, Double> } }.toMap()

Unsafe (relying on nullability check under

takeIf

), but doesn't create an extra list for filterIsInstance.

In fact,

associateByNotNull

could be helpful here if it was in stdlib

I guess, this is more practical, though is not academic: 😉

val map = mutableMapOf<String, Double>().apply {
    for ((first, second) in list) if (second != null) this[first] = second
}

@User uploaded a file: MutableLazy, with their implementations and commented: Hi, I think this would be a nice addition to the current Lazy interface + implementations. I can explain my complex use case if needed.

var foo by mutableLazy { 1 }

init {
  foo = 2
  print(foo)
}

What would the value of

foo

be when it's printed now?

1

or

2

? If it's 1, that's confusing. If it's 2, did the block ever get invoked (because it could potentially have side-effects)? Why or why not?

@User uploaded a file:

@kevinmost I implemented it on my side as I need it in my project, and as in the regular lazy, the initializer is called on the first get. For the mutable version, the initializer is dropped if set happens before, so in your example,

setValue

on `foo`'s delegate, which drops the non executed intializer and sets to the passed value, which is 2 and this is what will be printed.

why I’m able to pass

(Something)->R?

instead of

(Something)->R

?

private inline fun <reified K : Enum<K>, V, R> EnumMap<out K, V>.mapValuesIfNotNull(transform: (Map.Entry<K, V>) -> R?): Map<K, R> {
    return mapValuesTo(EnumMap<K, R>(K::class.java), transform) //                             nullable return type ^
}

@miha-x64 This happens because of platform types coming from EnumMap:

EnumMap<K, R>

is

MutableMap<K!, R!>

and therefore it's assignable both to

MutableMap<in K, in R>

and

MutableMap<in K, in R?>

(//cc @denis.zharkov)

Interesting.

HashMap<K, R>()

causes expected error, but, on the other hand,

private typealias EnumMap<K, V> = java.util.EnumMap<K, V>

does not help.

@miha-x64 I believe there are some special cases in compiler to eliminate platform types from generics of some JDK collections, please open an issue, so we could investigate whether they're applicable to EnumMap.

Ok, thank you. UPD. Done. https://youtrack.jetbrains.com/issue/KT-17566

Shouldn't

public operator fun <T> Iterable<T>.minus(element: T): List<T>

be defined with element as nullable?

public operator fun <T> Iterable<T>.minus(element: T?): List<T>

I.e. if you call

listOf<String>(...) - null as String?

it would just return the same

List<String>

and not

List<String?>

as it currently does. 1 reply Anyone has any input on this idea? I think such a change could be implemented without breaking any code using

minus

currently. It could even be changed to

element: Any?

, but I'm not sure this would be very useful.

Shouldn't

public operator fun <T> Iterable<T>.minus(element: T): List<T>

be defined with element as nullable?

public operator fun <T> Iterable<T>.minus(element: T?): List<T>

I.e. if you call

listOf<String>(...) - null as String?

it would just return the same

List<String>

and not

List<String?>

as it currently does. 8 replies

val list1: List<Int?> = arrayListOf(1, null).minusNullable(null)
        println("list1: $list1")
        val list2: List<Int> = arrayListOf(1, 2).minusNullable(null)
        println("list2: $list2")

compiles and prints:

list1: [1]
list2: [1, 2]

where

minusNullable

is a slightly changed

minus

operator (essentially argument type changed to

T?

):

fun <T> Iterable<T>.minusNullable(element: T?): List<T> {
    val result = ArrayList<T>()
    var removed = false
    return this.filterTo(result) { if (!removed && it == element) { removed = true; false } else true }
}

Shouldn't

public operator fun <T> Iterable<T>.minus(element: T): List<T>

be defined with element as nullable?

public operator fun <T> Iterable<T>.minus(element: T?): List<T>

I.e. if you call

listOf<String>(...) - null as String?

it would just return the same

List<String>

and not

List<String?>

as it currently does. 13 replies This has to investigated, whether it's possible to add something like this: https://github.com/JetBrains/kotlin/blob/1.1.0/libraries/stdlib/src/kotlin/collections/MutableCollections.kt#L15 so that type of element to be removed could be any direct supertype of element type of the collection.

Shouldn't

public operator fun <T> Iterable<T>.minus(element: T): List<T>

be defined with element as nullable?

public operator fun <T> Iterable<T>.minus(element: T?): List<T>

I.e. if you call

listOf<String>(...) - null as String?

it would just return the same

List<String>

and not

List<String?>

as it currently does. 23 replies https://youtrack.jetbrains.com/issue/KT-17569

My

MutableLazy

implementation is here: https://gist.github.com/LouisCAD/9b4ef46c12f1f6fe9b45658a8eff194c 3 replies Regarding the issue itself. I'm not against including it in stdlib, though the use cases have to be discussed. If you have some, do not hesitate to share in that issue's comments.

I think I've gone too far... thinking "there is no

fold

on

Map

in Kotlin".

what about

map.entries.reduce

?

Sure. I just used

fold

on

entries

. Like that I can deconstruct it

{ acc, (key, value) ->

@mesquka has left the channel

@john.shelley has left the channel

Can you spot the mistake:

fun foo(key: Bar) = cache.getOrPut(key) { return somethingSomething(key) }

2 replies Yes, removing the

return

solves the problem.

It got me thinking though: are there any cases when you want to bail out of

getOrPut

early with

return

statement?