Find a sub-block design

[paddycarver]

Historically, we've tried to make resources match their API counterpoints as closely as possible. In 0.12, it became clear we were thinking about sub-blocks structurally and core was thinking about them semantically, and our usage may not line up with the data structure. We should get to the bottom of this and align our data structures with what the intentions behind types, to better avoid breakage and unexpected behavior.

[paddycarver]

The understanding we reached is that the Object type (https://github.com/zclconf/go-cty/blob/master/docs/types.md#ctyobject-types) is probably the right solution for what we're calling "structural fields"--that is, in the following JSON

{
  "foo": {
    "bar": true,
    "baz": 1
  }
}

foo is a structural field. Right now we would implement that as a TypeList with a MaxItems of 1, but it's actually distinct from a list, which would look like this:

{
  "foo": [
    {
      "bar": true,
      "baz": 1
    }
  ]
}

The understanding is that the new Object type in cty gives us the semantics we're looking for there. An open question is whether users would need to specify all fields of an Object or whether they could set some subset, but I believe @jbardin indicated that it's acceptable for users to set some subset, which is what we need. I'm going to close this out, but am willing to be corrected if Object does not allow setting only a subset, in which case we need a new path forward.

Regardless, either way, we need a version of the SDK that exposes cty's types before we can do anything about this, so we're shelving it until such an SDK appears.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!