There's also the

lines

and

lineSequence

functions:

string.lines().joinToString("\n") { it.trim() }

.

this line:

chromosomes[foo] = bar

(

chromosomes

is

List<Double>

btw) gives me this error:

Unresolved reference. None of the following candidates is applicable because of receiver type mismatch:
@InlineOnly public inline operator fun <K, V> MutableMap<Int, Double>.set(key: Int, value: Double): Unit defined in kotlin.collections
@InlineOnly public inline operator fun kotlin.text.StringBuilder /* = java.lang.StringBuilder */.set(index: Int, value: Char): Unit defined in kotlin.text

i don't understand why...

it’s because you have a

List

rather than a

MutableList

Well, List doesn’t have

set

or any other mutating methods defined on it

ah

which is why the IDE is cycling through extension methods to find one with a matching signature

thank you

I agree it’s not a particularly helpful error 😕

aren't mutableLists (which are literally java arraylists) significantly more performance impacting than a list?

it depends

😁

I’m pretty sure the list you get from

listOf

with more than one element is backed by an arraylist

and yeah, it really depends on what you mean by “performance impacting”

if you are to use them correctly, with defensive copying etc, they are mich slower

if you use them as most people do, they are same or faster

collections kinda really screw with the easy-to-understand nature of kotlin's mutable vs immutable properties

I mean,

val/var

isn’t really about the mutability of objects so much as it is the mutability of references

it’s not like Swift where

let

will disallow access to mutating methods on a struct and

var

will allow it

right, i think that's mostly what i'm referring to. there's a kotlinx library that adds immutableLists, but what about a list that you can add/remove elements, but cannot change the value of those elements?

i haven't written in swift but typescript does the same thing

but isn’t changing value of an element just a remove followed by an add?

add at certain position

... fair point ... i'm an idiot

okay, so then a collection you can add to, but can't remove or change the values of

isn't that what a block chain is?

I don’t know much about computers, but I will say that in my personal experience, that kind of data structure is much more niche than our usual concepts of mutable vs immutable collections

I think what we have right now with the new ImmutableList and our existing List/MutableList paradigm is easy enough to reason about once you get the handle of how references get used in Kotlin and Java

Not sure about Kotlin, but in Java,

List

interface declares all modifying methods optional. So you could wrap your favourite List implementation and make all the modifying methods you don’t like throw

UnsupportedOperationException

of course, that wouldn’t allow the compiler to tell you exactly what it thinks of you when you call those methods