I am wondering if there could be an alternative to that pattern. What about having a "catch all" field in such structs. And we validate that that's empty? Just an idea. Not sure it works. But it might be less intrusive.

Thats essentially whats happening, with the flattened HashMap in InnerCfg. To do this we create a seperate struct with the field we want flattened being replaced by the HashMap. After we get InnerCfg, we take its remaining fields, and try to fill the Core. Any remaining field after that stage would mean there is a top level field that is incorrect. Inner fields (build.dist, ...) are simply handled by the types in the fields.

I am open to other solutions, its just that this is the only solution I could find that gave out good error messages, and was fully contained into a single module. Its completely possible I am missing something though.

I am wondering if there could be an alternative to that pattern. What about having a "catch all" field in such structs. And we validate that that's empty? Just an idea. Not sure it works. But it might be less intrusive.

The issue with your suggestion is that once we do that we might end up with false alarms when a change is introduced. A flattened field does not guarantee that it will actually use the fields (or rather mark them as used). Which means we cannot flatten Core and store the remaining fields with a flattened HashMap without risking a false alarm. We can technically avoid this by storing the field names as a string and compare it to the keys in the HashMap, however this gives quite a bit of room for mistake when a new field is added/removed (I think Core is getting deprecated anyway so this might not be an issue?). See https://serde.rs/attr-flatten.html#capture-additional-fields. One more thing is the error messages will (in most cases) contain less information compared to the one returned from the deserializer.

See related serde issues: serde-rs/serde#1358, serde-rs/serde#2200, serde-rs/serde#2764

From what I can tell this is mainly a problem with enums but since this isn't explicitly documented I didn't want go down that route.

I am aware this solution isn't ideal but on the other hand any solution that isn't hacky would require changes on serde's end. Based on what I read in the issues it wont be anytime soon as it would require updates to libraries like serde_json, yaml... Which means it will be a while until we get a solution that works well and isn't a hack. Since we only flatten one struct in Configuration this seemed the safest way to do this.