What's the design decision behind setting `ignoreUnknownKeys` to `false` by default? I can't see any...

# serialization

[reactormonk]

What's the design decision behind setting ignoreUnknownKeys to false by default? I can't see any reason why anyone would want that in production, it makes protocol upgrades especially painful. Yes, I can change it, but it looks like something you figure out after a downtime. https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-cbor/kotlinx.serialization.cbor/-cbor-builder/ignore-unknown-keys.html

[Adam S]

It looks like there's a lot of info about the reasons in the PR and associated issue - does this help?

https://github.com/Kotlin/kotlinx.serialization/pull/947

[reactormonk]

Reading the comments I didn't see a single one on the default, I guess it was a new feature and it was common sense to disable it by default?

[Ben Woodworth]

It looks like ignoreUnknownKeys was added to JSON in the third commit of this PR, replacing strictMode (which was true by default, disallowing nonstandard JSON) with the ignoreUnknownKeys option and a couple others. No specific comments/rationale that I can see there eother. But I imagine the CBOR config used JSON as the precedent

It does feel like it comes down to use case though. For me, I can't have information loss when I'm reading data, so passing forward an in-memory class representation that doesn't capture the original data would be problematic in my case working with data. And if the default did ignore keys, I could have the opposite problem, except without ever knowing

[reactormonk]

I've always hated that part of jackson, where you had to exactly match the json part in production, otherwise the system would blow up. IMO strictness is something you should only be using during development, if at all.