When will we get to play around with kotlin/native...

# kotlin-native

[spierce7]

When will we get to play around with kotlin/natives new memory model for sharing objects between workers?

[olonho]

You may do that already: https://github.com/JetBrains/kotlin-native/blob/master/backend.native/tests/runtime/workers/freeze0.kt

[olonho]

https://github.com/JetBrains/kotlin-native/pull/1390 for more context

[spierce7]

Interesting! It's not exactly how I imagined it. I assumed it'd have been built as a keyword on a class, that after it was created would be immutable. i.e.

frozen data class SharedData(val string: String, val int: Int, val member: SharedDataMember)

The current api has it's own merits, but being able to declare a data class as frozen / immutable would be a nice addition as well. Are there downsides to building it into the class definition in addition to the approach currently implemented?

What is the plan to integrate this with common projects so that we can write common code that works properly with kotlin/native's threading model, and in Java / JS as well?

[msink]

const data class

[msink]

I mean - no need for new keyword, const already exists and means exactly that - immutability.

[olonho]

it has different semantics. Most important one is that data could be freely manipulated until frozen, unlike const/final, which is constant immediately. Sugar with autofreezing some classes after ctor completed could be added a bit later.

[msink]

That const classes can be placed in read-only memory, and without reference countiong.

[olonho]

sure, I am just saying that freezing has different semantics

[spierce7]

@olonho What is the plan to integrate this memory model with common projects so that we can write common code that has proper error handling and can compile properly to all the platforms? I suppose the worker concept would have to be multi-platform as well, so I guess we're a ways from that?

[olonho]

it is being discussed, but not sure if it will be available soon. In many cases, object sharing mechanism is platform dependent, so common code can hide it behind some facade

[spierce7]

ideally there'd be a way to at least opt-in to ensuring that common code would properly compile to all platforms. Otherwise it becomes pretty annoying.