From general: Why I can do

plus()

on map, but can’t

minus()

? Basically I have immutable map and I need to remove item from it and get new immutable map as result.

@kittinunf has left the channel

That makes sense

@artem_zin: What would you expect from

Map.minus

operation? Should it take a key as an argument or a key-value pair like

Map.plus

do?

@ilya.gorbunov: all overloads as

Map.plus()

has?

Could you show how would you use

minus

with a code example?

var map = mapOf(“s” to 1)
map -= “s"

Valid variants: *

minus(key)

*

minus(Iterable<Key>)

Looks like there is no much sense in giving api to remove by key value pair, only key matters for

minus

.

We had such operators in stdlib before 1.0 release, but we felt it's kinda unintuitive that

minus

is not symmetrical with

plus

, i.e. takes a key, whereas

plus

takes a pair, so we decided not to provide them. We may reconsider that decision.

@ilya.gorbunov: how would you remove something from immutable map then? I can’t use

remove(key)

because it returns removed value and not the new map. I see two ways at the moment:

filter

(which is slow obviously) or create new mutable map with content of previous, remove item from it, then make it readonly.

If you have a

MutableMap

you can do just

map.keys -= key

, but for read-only maps there is no easy way for now.

how do you expect minus to be implemented for immutable maps if not one of those two options?

filter

might be faster than your second suggestion since the entries can be re-used instead of copied

I have a proposal somewhat related to the Immutable collections. It would be very handy if Kotlin's stdlib created a MultiMap like Guava. I've used it heavily and built API's around it. https://github.com/thomasnield/tom_common_kt/blob/master/src/main/kotlin/org/nield/common/SequenceOperators.kt#L25:L29

@User uploaded a file: Untitled

@jw: for immutable maps we're going to have

ImmutableMap.remove(key)

member function which returns new

ImmutableMap

instance

right. sorry my question was for artem since both of his suggestions are two of the options which would back such a method anyway.

@jw: I meant the amount of code in userspace, of course it would be implemented like this in stdlib

Oh wait,

groupBy()

kind of does that already. As long as

groupBy()

has some form of

ImmutableList

equivalent I'll be cool with that.

Which asks the question... will the Immutable Collections be the default collections with functional API's like

Sequence

?

groupBy

returns read-only map of read-only lists. Is read-only sufficient, or do you need immutability?

I don't need immutability, but I like it. I understand it performs better and I'm a bit OCD with immutability I'll admit. Nice thing about Kotlin is I can always implement my own extension functions and build my own API. But personally I think immutability would have been better over read-only collections. But I understand the Java interop goals prevented that.

I don't need immutability, but I like it. I understand it performs better

usually it does not

That is surprising. Maybe my information on Google Guava is dated. I remember

ImmutableList

boasted some pretty sizable performance over

ArrayList

.

This has to be weighted carefully before we could give an answer. I.e. what would be an impact on the standard library size and method count and what performance implications would follow.

@ilya.gorbunov: so, looks like

map.minus(key)

and

map.minus(keys)

deserve to live in stdlib?

@artem_zin: likely so

I can create a ticket for that in youtrack and try to make a PR, does it sound good to you @ilya.gorbunov?

You can just create a ticket, and the implementation could be restored from github history: https://github.com/JetBrains/kotlin/commit/300a4be06097184688d80e16025cbcd0bffdfb6a

Here you go https://youtrack.jetbrains.com/issue/KT-13353

I'm not seeing a

fun <T> List<T>.replace(index: Int, new: T): List<T>

function. Should one exist in stdlib?