Is it necessary that properties without backing fi...
# serialization
g
Is it necessary that properties without backing fields are serialized?
k
Barring global variables they should be derivable from the actual state of the class, so no?
g
yeah — that's my assumption too. But looking at the compiled code for my classes, kotlinx.Serialization seems to serialize them. Actually I think this is probably a bug. It even generates a new constructor, where the constructor tries to set fields that don't exist
s
I think there should be an assertion in plugin somewhere, which forces user to mark such properties as
@Transient
. If you have an example with compiled bytecode, please file an issue on github.
g
Couldn't they be excluded automatically?
s
We don’t have an opt-in annotation (inverse to transient), so if there is a need to serialize computed property (e. g. for external client or for logging), auto-exclusion would made this case impossible