Can I assume a `mutableMapOf()` to preserve iterat...

# announcements

[mbonnin]

Can I assume a mutableMapOf() to preserve iteration order on key re-insertion like a LinkedHashMap ?

[Ryan]

no you can’t

[spand]

Would be nice of them to provide that guarantee though

[mbonnin]

That answers it, thanks

[mbonnin]

It's very tempting to assume it

[Ryan]

linkedMapOf()

[Ryan]

boom

[mbonnin]

On the JVM it's all the same

[mbonnin]

mutableMapOf() calls LinkedHashMap() which is why it's very tempting to assume the same API as LinkedHashMap

[mbonnin]

But maybe on other platforms it's different?

[spand]

LinkedHashMap is a kotlin type

[mbonnin]

Doesn't it alias on the JVM?

[mbonnin]

mmm, right no it doesn't

[spand]

Pretty sure it does

[spand]

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-linked-hash-map/#kotlin.collections.LinkedHashMap

[mbonnin]

ok yes, it makes sense then 👍

[spand]

There are no docs though so its hard to say but seems pretty safe assumption that it will be identical to javas on all platforms

[spand]

Maybe a question for #stdlib

[Nir]

I feel like, even if the assumption is "safe" it's still better to use the more specific function, and even type

[Nir]

it documents intent, and also, it may end up protecting your code (depending on how things are written, or modified in the future)

[mbonnin]

The question whether LinkedHashMap keeps order on re-insertion remains

[Ryan]

Why does the order matter for a map?

[spand]

A workaround could be to assume so and make a test that verifies in order to guard against it giving you a heads up

[Nir]

Sorry can you clarify "re-insertion"

[Nir]

are you saying, if you do x["foo"] = 5

[Nir]

if "foo" is already present in the hash table, then you want the value to be changed, but not the order?

[mbonnin]

@Nir yes, exactly

[mbonnin]

The JVM LinkedHashMap has a specific note about it but it's not mentioned in the Kotlin doc

[Nir]

yeah, guess you'd need to ask the stdlib maintainers to clarify that point

[Nir]

you're interested in all 3 targets?

[mbonnin]

TBH, the code only runs on the JVM at the moment but I like to write something that's as platform agnostic as possible as it might be compiled to native at some point

[spand]

I created an issue for it
https://youtrack.jetbrains.com/issue/KT-43082

[mbonnin]

Thanks !

[Nir]

A good workaround for now might be to create an alias, and use that. If it turns out that the native type does not give the guarantees you need, you should be able to change the alias (hopefully conditionally if necessary)

[Nir]

I'd probably also clarify what's meant by "assume order of re-inserted keys", because allowing users to assume that the order is that re-inserted keys get moved to the front is also a valid choice

[gildor]

no you can't

This is incorrect! Please check documentation of this function:
The returned map preserves the entry iteration order.

[mbonnin]

The "key" (pun intended 🙃) word up there is "re-insertion"

[mbonnin]

For now I'll keep iterate Lists I think, it's a bit more verbose/less optimal I think but at least it'll make it explicit that the order is kept

[Nir]

@mbonnin that's a bit tricky to get right

[Nir]

in the face of deletions