When decoding, a nested struct could be squashed with the mapstructure:",squash" struct tag. A similar functionality appears when marshalling JSON into structs, but it is called inline instead of squash.
Given that a DecoderConfig field allows specifying a different name than mapstructure for the struct tag, I think users would want to be able to specify a different value to indicate the "squashing" of nested structs.
Indeed, such functionality would allow a more satisfactory resolution to spf13/viper #1050. While it remains true that users may specify a struct tag of `mapstructure:",squash", it is sometimes not possible to do this because the structs are not owned by the current package. If this is merged, users will be able to correctly parse configuration that contains foreign types that have nested structs that need to be inlined with something like:
When decoding, a nested struct could be squashed with the
mapstructure:",squash"struct tag. A similar functionality appears when marshalling JSON into structs, but it is calledinlineinstead ofsquash.Given that a
DecoderConfigfield allows specifying a different name thanmapstructurefor the struct tag, I think users would want to be able to specify a different value to indicate the "squashing" of nested structs.Indeed, such functionality would allow a more satisfactory resolution to spf13/viper #1050. While it remains true that users may specify a struct tag of `mapstructure:",squash", it is sometimes not possible to do this because the structs are not owned by the current package. If this is merged, users will be able to correctly parse configuration that contains foreign types that have nested structs that need to be inlined with something like: