Fallback value for unknown enum values

[Nohus]

When deserializing enum values, it would be useful to specify a fallback value, in case a remote API introduces a new value for the enum.

Example:

enum class Color {
    Red,
    Green,
    @FallbackEnumValue
    Unknown,
}

data class Scarf(val colors: List<Color>)

Then, the following JSON:

{ "colors": ["Green", "Blue", "Red"] }

Would result in:

Scarf(listOf(Green, Unknown, Red))

Another use case would be an API returning an enum with many possible values, where the client only cares about a subset of them, and would like to consider all other as a single "Other" value.

This is supported in Jackson as @JsonEnumDefaultValue.

There was a similar issue #90, but it asked for the ability to use the default value as declared on the use site of the enum, which is different and not applicable to the above example.

[LouisCAD]

I think an equivalent to coerceInputValues but as an annotation for use-site would also be nice and support null:

@Serializable
data class Something(
    @CoerceInputValues val type: Type? = null
)

Could also be called @SerializeDefaultOnUnkown, or something else.

[Nohus]

@LouisCAD What you are describing is more of a solution for the other issue I linked.

• I am looking for a declaration-side solution, so that you don't need to do it in 20 places if you use that enum in 20 places.
• It wouldn't work for collections, like my example shows.
• You might want a default value that's different from the fallback value, so coercing to default doesn't work for all cases. For example val color: Color? = null, I want null if there is no color sent, but Unknown if there is a color, but the client doesn't support it. The API not sending a value is a normal valid case, where it sending an unknown value needs to be handled differently.

[LouisCAD]

On the other hand, the issue you linked was closed without any such solution, nor reply from the concerns of putting it at the use-site.

There are basically 3 levels, and depending on the project's specifics, we might need a different level:

1. Json { … } config level (already implemented to some extent with coerceInputValues, lacks connection to the affect symbols, no fine-grained control)
2. enum declaration level (what you are asking for), works everywhere the enum is used.
3. use-site (what I also want as an option), works where the enum is used, if specified, and nowhere else.

I think we can have this issue be about those 2 latter levels, unless a maintainer asks us to split it, or decides to provide a solution for only one of the 2 missing levels (🥲), do you agree?