Collection Types & Builders

buildList gives you a temporary mutable list to fill inside the braces, then hands back a normal read-only List. You add items with add(), and the final list cannot be changed afterward.

Use listOf(1, 2, 3), setOf(...), or mapOf("a" to 1) to build collections quickly. They give you read-only collections you cannot add to or remove from.

map[key] gives you null when the key isn't there, so the result type is nullable. map.getValue(key) instead throws an exception if the key is missing, returning a non-null value when it exists.

Kotlin's default maps and sets keep elements in the order you inserted them. They are backed by LinkedHashMap and LinkedHashSet, so looping over them gives you items in insertion order.

List only lets you read items. MutableList lets you also add, remove, or change them. The same idea applies to Set/MutableSet and Map/MutableMap.

A read-only List only lacks add/remove methods on its interface. The actual object behind it can still change through another reference. Read-only means 'you can't change it', not 'nobody can'.

Array<Int> stores boxed Integer objects; IntArray stores raw int values directly. IntArray uses less memory and is faster because it skips the boxing, so prefer it for numbers.

Inside the braces, 'this' is a temporary mutable map. You add entries with put or with map[key] = value, and you can overwrite existing keys the same way. When the block ends you get a read-only Map back.

listOf gives a read-only list; mutableListOf gives one you can add to and remove from. Use mutable only when you actually need to change the collection after creating it.

All three give a value when a key is missing. getOrDefault takes a ready value. getOrElse runs a function only when needed. getOrPut also runs a function when needed but stores the result back into the map.

If you return the same backing list, the caller's read-only reference still changes whenever your class mutates the field. Returning field.toList() makes a copy, so the caller gets a snapshot that can't change underneath them.

Sets and map keys decide 'same element' using equals() and hashCode(). If two objects are equal they must have the same hashCode. If you change a key after inserting it, the set can no longer find it.

Use toTypedArray() to get an Array<T>, toIntArray()/toLongArray() for primitive arrays, and toList()/toMutableList() for collections. Each one copies the data into a new container.

Each builder accepts an optional initial capacity so the backing collection is pre-sized and resizes less. Builders also let you assemble a result in one pass with conditional logic, avoiding the many intermediate lists that chained operators create.

emptyList() gives a typed empty collection (often a shared singleton). listOfNotNull(a, b, c) builds a list but skips any null arguments, so you do not get nulls in the result.

A read-only List<Cat> can safely be treated as a List<Animal> because you only read from it. A MutableList<Cat> cannot, because you could try to add a Dog, so it must stay exactly its type.

It depends on the real object. listOf may give an unmodifiable instance that throws when you try to add. mutableListOf gives a real ArrayList, so the cast-and-add succeeds. Both compile, but casting back is unsafe.

For arrays, == checks identity (same object), not contents, so two different arrays with the same values are not equal. Use contentEquals() to compare values, and contentHashCode()/contentToString() for hashing and printing.

No. buildList returns a read-only view, not a deeply immutable list. You can't change it through the returned reference, but if you kept the mutable reference or the elements themselves are mutable objects, those can still change.

'to' is a small function that builds a key-value Pair, like "a" to 1. mapOf takes those pairs. It is just a Pair, so it has no special map magic.

Use the read-only type (List, Set, Map) almost everywhere — for inputs you only read and for things you return. Only use the Mutable type when the function or caller really needs to change the collection.

The read-only type only hides change methods at compile time. The real object underneath is often a normal mutable ArrayList, so anyone holding a mutable reference to it, or a cast, can still change it.

Java doesn't know about Kotlin's read-only vs mutable split. A Kotlin List is a plain java.util.List to Java code, which can call add/set on it. And collections coming from Java arrive as platform types Kotlin can't fully police.

No. getOrPut on a normal map is not thread-safe: two threads can both see a missing key and both compute and store a value. For safe concurrent lazy init use a concurrent map's computeIfAbsent.

buildSet works like buildList but the temporary collection is a set, so adding a duplicate is ignored and add returns false. Like other Kotlin sets, it keeps elements in insertion order and returns a read-only Set.

Kotlin guesses the element type from the arguments you pass. Mixing types gives a common supertype like Any. You can pass an existing array into the vararg using the spread operator *.

A read-only view doesn't stop the underlying list from being changed by another thread. One thread can iterate while another mutates the backing list, causing inconsistent reads or exceptions. A copy or a truly immutable list avoids this because nothing can change it.

In Kotlin you cannot pass an Array<String> where an Array<Any> is expected — arrays are invariant. This prevents a class of runtime errors that Java's covariant arrays allow.

The List type only hides change methods; it is not a promise of immutability. To truly prevent changes you copy the data, keep the original hidden, or use a special immutable collection library.