the only thing I miss from kt is real immutability...

# language-proposals

[Pere Casafont]

the only thing I miss from kt is real immutability like cpp's; in there, if some object is const, you can only read its fields and call only its const methods (which guarantees the object is not going to change)...but right now there's only "pointer" immutability. Any thoughts on that?

[Ruckus]

Just define you're class with all `val`s

[benleggiero]

No, I see where @Pere Casafont is coming from. This is something I miss from Swift. Sadly, it’s a limitation of both JVM and JS, so if it is ever implemented, it will be Kotlin/Native exclusive (which doesn’t sound like something JB would do).

For context, in Swift, no matter whether a `struct`’s members are `let`s or `var`s, if the object is declared as a let, its members cannot be changed. This is a huge strength of value types. Additionally, if it’s a var, then any mutation creates a new object in memory, so the original’s is not mutated. This copy-on-write creates so much peace-of-mind that I feel safe doing pretty much anything to any struct at any time. They’re inherently thread-safe and inherently immune to concurrency side-effects. They still require a gentle touch if you want to ensure just one value comes out of a concurrent operation, but at least you will know that whatever comes out wasn’t stepped on by many threads.

Can’t wait for Kotlin value types. Hope they’re as useful as Swift’s!

[snrostov]

Sadly, it’s a limitation of both JVM and JS

JS supports freeze on object and arrays

Object.freeze(arr);
Object.isFrozen(arr);

[Pere Casafont]

this doesn't need runtime checks, it can perfectly be enforced by the compiler, exactly like the null safety, so I don't understand why it should be exclusive for kt native

[cypher121]

@Pere Casafont because it would create a weird situation where kotlin code can't modify the object's properties, while Java code can, because it has no such compiler check

[Pere Casafont]

like with null safety: you can send a Thing? to java and it will be able to do thing.whatever without any issues

[Pere Casafont]

I don't think that's a good enough reason

[snrostov]

you can send a Thing? to java and it will be able to do thing.whatever without any issues

Kotlin compiler insert null-checkes on every public method. The same should be for mutable methods of immutable objects.

[Pere Casafont]

ok, I get it now

[benleggiero]

Don’t forget that JVM bytecode created by Kotlin is still manipulatable by other JVM languages like Java which won’t respect its compile-but-not-run-time immutability. Same with pre-ES5 JS.

[codejanovic]

I dont think that makes any Sense and is more a smell than a benefit. Either the objeft is immutable (through its whole lifecycle), or its Not.

[codejanovic]

So you Can create a mutable object in c++ in class A, and Pass it to a method of class B with a const prefix, so that class B May Not modify its state?

[Pere Casafont]

Exactly. It is a way to know for sure certain object will not be ever changed in certain place. Debugging gets easier that way, and you can pass important object references as return values without having to copy them just in case.

[codejanovic]

Yeah I understand, but i would call it a myth that debugging gets easier. the core problem exists: while you are working with that const prefixed object in place B, there is absolutely no guarantee some other place (where it is passed without that const prefix ) will change the objects state you are currently working with. this is is the same mutable debugging hell, just deferred a little bit 😛

[Pere Casafont]

I know that, as I said it's more of a compile-time restriction to make sure no one touches where they shouldn't than a way to know an object is not going to change

[codejanovic]

okay