When a developer declares a type both @Observable and Codable, there is a bad surprise: the Observable macro transforms regular properties into computed ones, and adds new properties, prefixed by underscores. Codable then only deals with underscored properties.
In the end, the type gets a "corrupted" Codable facet due to Observable:
No one expects coding keys to be prefixed with underscores.
Adding @Observable to a working Codable type breaks its Codable facet, because it can no longer decode previously encoded data. This is pretty bad, actually, because this breaks the strong compatibility contract of Codable.
Motivation
Hello,
When a developer declares a type both
@Observable
andCodable
, there is a bad surprise: the Observable macro transforms regular properties into computed ones, and adds new properties, prefixed by underscores. Codable then only deals with underscored properties.In the end, the type gets a "corrupted" Codable facet due to Observable:
@Observable
to a working Codable type breaks its Codable facet, because it can no longer decode previously encoded data. This is pretty bad, actually, because this breaks the strong compatibility contract ofCodable
.I was aware of this problem from two sources:
In both cases, developers were completed puzzled.
And workarounds are not pretty. Basically they ruin the most valuable aspect of
Codable
, which is the convenience of compiler-synthesized code.Please consider solving this issue. Standard components such as
@Observable
andCodable
should not conflict together.Proposed solution
I don't have any ready-made solution. I expect that we'd need to give much more powers to macros.
Alternatives considered
No response
Additional information
I submitted the same report as FB13756604 (The Observable macro does not play well with the standard Codable protocol)