cty/json: Allow unsupported fields in json

[akupila]

Currently when we unmarshal json using cty/json to an object, all fields in the type must match the incoming json:

https://play.golang.org/p/REla4iDJbaQ

While i suppose you could call this a feature (the data doesn't match the type), it makes it difficult to allow the type to be forwards compatible with external json. I would expect it to behave similar to the go stdlib json, where fields that are not set in the target struct are silently ignored.

I think changing the check to skip the field rather than return an error would do this (but that's probably a backwards incompatible change?):

go-cty/cty/json/unmarshal.go

Lines 313 to 316 in 15177b9

	aty, ok := atys[k]
	if !ok {
	return cty.NilVal, objPath.NewErrorf("unsupported attribute %q", k)
	}

I'm happy to put together a PR but would like to get your thoughts first and also what you think the best solution would be.

[akupila]

Perhaps this is not necessary, this seems like a reasonable workaround: https://play.golang.org/p/rvjnUJZOvRU

[apparentlymart]

Hi @akupila! Sorry for the slow response here.

The json package here was intended to prioritize being explicit, so the strictness you refer to is conceived as a feature rather than a bug. However, as you've noted it can be useful to take a more flexible approach when dealing with interchange between different systems or different versions of the same system, which includes not only allowing for undeclared attributes but possibly other allowances, such as an attribute that was previously defined as a number but is now a string.

The explicit conversion approach you found in your second playground example here is nice, I think, because it accommodates various sorts of structural differences as long as there's a type conversion available for them. For that reason, I'm going to close this with the recommendation of using the conversion approach you found in situations where a less-strict approach is warranted.

Thanks for raising this, and thanks for sharing the compromise approach you found!