A modern programming language that makes developers happier.

kotlinlang

Is there a map type that remembers the order of insertion?

`LinkedHashMap`

also the default map implementations in Kotlin (`mapOf` / `mutableMapOf`) preserve the order of insertion (aka are backed by `LinkedHashMap`)

default including the return types of `associate*`, `toMap`, etc.

of course if you explicitly use `HashMap` (or specific other concrete types that don't preserve ordering) then of course it won't be ordered by insertion

The return type of `mutableMapOf` is `MutableMap&lt;T&gt;` though, which in my book means that the function reserves the right to change which implementor it instantiates in the future. How do I make sure it’s a `LinkedHashMap`?

<https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.collections/mutable-map-of.html> it is documented that
&gt; The returned map preserves the entry iteration order.
it doesn't matter if it's a `LinkedHashMap` or some other type of map that preserves insertion order, but it does

What’s the difference between iteration order and insertion order? The `LinkedHashMap` docs specifically use the term insertion order, which is not what `mutableMapOf` promises. Also please understand I’m not trying to start a semantic debate in bad faith, I’m just not used to this level of imprecision in documentation and in type signatures.

Could you please elaborate what you mean by "imprecision in type signatures"?

there is no interface for "`Map`s which have a consistent iteration order", and it would be unreasonable to make `mapOf()` return `LinkedHashMap` - it can return a singleton instance for the empty map, for example.

as `Map` itself is not ordered, so the only order is the one in which `entries` (and correspondingly `keys`/`values`) are iterated, which (for the ones produced by stdlib functions) follows insertion order, which is also what `LinkedHashMap` does

<@U08RRG4EUR5> How `mutableMapOf` for example returns a `MutableMap&lt;K, V&gt;`, not a `LinkedHashMap&lt;K, V&gt;` or a similarly more precise type that locks in the supposed promises.
&gt; no interface for "`Map`s which have a consistent iteration order"
There’s no reason there couldn’t have been such an interface, not that I think there should be one.
&gt; it would be unreasonable to make `mapOf()` return `LinkedHashMap`
I disagree, because multiple possible solutions exist to avoid an unnecessary allocation, employed by other existing languages.
• A `sealed class` subtyped by a singleton `object` that’s empty and a `class` to be populated.
• A `lateinit` pointer to the heap buffer (or another means of deferral) that’s not initialised until the map is populated.
And so on. Anyway, I don’t mean to start an argument, and I’ve decided to use a `List&lt;Pair&lt;K, V&gt;&gt;` instead because I don’t need to look up keys.

for keeping stdlib lightweight and ease of Java interop (unlike Scala), Kotlin's collections hierarchy largely mirrors Java, except for having Mutable which is sorta erased. there isn't a general way to add new interfaces to existing types

if you want to allow duplicates and don't need lookup then `List` is fine