oh yay I just got to my first "a mutable property that could have been changed by this time" error.

# getting-started

[keturn]

oh yay I just got to my first "a mutable property that could have been changed by this time" error.

[Hamza]

use let

[keturn]

yeah, that looks like it's probably the best option for this case

[keturn]

but leaves me wondering, is there any way to declare something to be run single-threaded, so we don't need let to make copies?

[Hamza]

make a new val and make it equal the var

[Andreas Sinz]

@keturn you can't declare that in kotlin

[tddmonkey]

Isn’t there something in contracts that is going to help with that?

[Hamza]

Not for mutable values

[Sam]

@keturn even if it was possible, it opens the door for bugs say if someone new to the code base didn't understand that single threaded assumption. Compile time constructs are a bliss

[Andreas Sinz]

Kotlin won't have such a feature in the near future, because it can lead to nasty bugs when the compiler can't prove that the annotation is still correct https://youtrack.jetbrains.com/issue/KT-20294

[keturn]

To keep it a compile-time construct the compiler would somehow have to be able to trust that the object was thread-local. (or if shared, the only thread that may mutate it is the current thread)

and yeah it may well be we don't have any way to communicate that in an enforceable way to the compiler.

[keturn]

thanks for the link to the youtrack ticket, the discussion there seems very thorough.

[keturn]

(and I'm very sympathetic to Mitja's point that there are environments like Kotlin/JS that are always single-threaded.)

[keturn]

I also realized that let is not copying the value of the property, but probably just a reference to that current value, which is a little less worrying resource-wise.

[Andreas Sinz]

Why does the property have to be var?

[Andreas Sinz]

What about lateinit? https://kotlinlang.org/docs/reference/properties.html#late-initialized-properties-and-variables