Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support array content equality when deciding whether to encode a default value #2409

Open
drewhamilton opened this issue Aug 9, 2023 · 5 comments
Assignees
Labels

Comments

@drewhamilton
Copy link

What is your use-case and why do you need this feature?

For most properties, the behavior of encodeDefaults or @EncodeDefault is determined by an equals check against the property's default value: If encodeDefaults is false and equals is true, the property doesn't get included when serialized.

For array properties, this doesn't work well, because arrays don't implement content-based equals. Thus, for example, an empty array property value registers as not-equals to the empty array default property value, and the empty array is included in the serialized output.

cashapp/redwood#1395 wants to migrate its public API List properties to Array types, primarily because of performance impact on JS.

Describe the solution you'd like

Support content-based rather than reference-based comparison when determining the encodeDefaults behavior for array properties. This could be by default or via a property annotation.

@sandwwraith
Copy link
Member

Given that .equals on arrays aren't as useful, I think the behavior can be changed. Although, it has to be a bugfix in compiler plugin, so it will take some time until it's available in the Kotlin release

@drewhamilton
Copy link
Author

Any thoughts on when this could be implemented? Any chance of landing around Kotlin 2.0 release?

@sandwwraith
Copy link
Member

Tbh I forgot about this, so it does not have any plans or particular date

@JakeWharton
Copy link
Contributor

Now that Kotlin 2.0 is out do you think this is something that could be put into future consideration?

@sandwwraith
Copy link
Member

Yes, I think it is something that can be done now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants