easiest way to cast a mutable list into a list?

# getting-started

[mgrazianodecastro]

easiest way to cast a mutable list into a list?

[hfhbd]

No cast needed?

[Casey Brooks]

Don’t cast it, use .toList() instead. If you cast it, someone else could cast it back to a mutable list and modify it in a place where it should be treated as read-only

[Vampire]

They could even then, couldn't they?

[Vampire]

Effectively at least

[Vampire]

Afair you don't get an unmodifiable list from that, just a normal list but with List as return type

[Casey Brooks]

It’s not strictly unmodifiable like an immutable collection, but the return type is a read only list, and the specific implementation may or may not actually be ArrayList. But regardless, even if the result of toList() is an instance of ArrayList (which implements MutableList), it’s still a separate instance, and thus prevents changes to the original list

[mgrazianodecastro]

I don't have such method 😭

[Casey Brooks]

Make sure to look at the return types of your function calls. .add() does not return a list

[mgrazianodecastro]

oh, you're right. Such a noob lol

[mgrazianodecastro]

it worked, thanks

[Klitos Kyriacou]

If the list is very large so that it is undesirable to copy it by calling toList() , then (if you're on the JVM) you can wrap it using Collections.unmodifiableList(colors) as List<Color>

[Joffrey]

Also you should consider builders like buildList { ... } if you temporarily need a mutable list during construction but then want the result as List. That said, in your specific case you should consider List(10) { Color.Black } + Color.Transparent

[Vampire]

That misses a transparent in the beginning 😉

[Klitos Kyriacou]

But that misses the point Casey Brooks was making: that someone could still cast it back to the ArrayList that it is, and modify it. Though I don't usually worry about such things. If a programmer that uses my API wants to be malicious, they can be malicious in many more ways than casting a List to a MutableList.

[Joffrey]

@Vampire oops I had missed it, then it's not so nice with direct list additions: listOf(Color.Transparent) + List(10) { Color.Black } + Color.Transparent. I guess buildList would be the best approach here.

[Joffrey]

@Klitos Kyriacou yeah the idea is that it might not have been a requirement. The question looked like an XY problem. Also, I agree, usually not a thing I think about as long as the compile time type is read-only. If people want to mess up, they will

[Klitos Kyriacou]

There are some cases where defensive copying is desirable: for example, an enum's values() method returns a newly created array each time it's called. This is because in Java and Kotlin there are no read-only arrays, and the compiler doesn't prevent accidental modification of the returned array's values. But for List, that's different.

[Joffrey]

an enum's values() method returns a newly created array each time it's called

But we're not the ones making defensive copying in business code. In Kotlin we usually deal with lists for this reason. Also incidentally the enum entries will soon be lists 😄

[Klitos Kyriacou]

It will be great when the enum entries will be lists. It would have been nice if they were from the very start, but I guess enums appeared in Java before it had the new collections framework (and Kotlin just uses Java's enums)