Update go-cty and improve documentation for optional and default attributes

[liamcervante]

• Update the typeexpr README with some discussion of optional and default object attributes
• Remove references in the godoc that state you should apply defaults before conversion
  • instead, recommend that you should actually convert first
  • the latest versions of convert will introduce null values for optional attributes, and the default functions in hcl will overwrite null values (note, there are actually tests for this already)
• Update go-cty to the latest version
  • go-cty is now much more flexible around unsafe conversions so some tests started failing because they expected go-cty to not be able to do conversions that it can now do
  • added new tests that test more complex behaviour, and verify the old tests are now expected to succeed.

[alisdair]

Docs changes look good to me, thanks! I don't really understand the test updates, which makes me a bit nervous. I left a question inline.

[alisdair]

I am surprised that you were able to make this test fail by changing it in this way. An attempt to recreate this in a terraform console session:

> true ? tolist([[1]]) : tolist([[2,3]])
tolist([
  tolist([
    1,
  ]),
])

> false ? tolist([[1]]) : tolist([[2,3]])
tolist([
  tolist([
    2,
    3,
  ]),
])
>

Neither of these error. Am I missing something?

[apparentlymart]

I think the key here is that the two elements of the "2-tuple" must be of types that have no common base type, or else HCL will notice that it can convert the two tuples into lists of numbers to find a common type.

> true ? tolist([[1]]) : tolist([[2, true]])
╷
│ Error: Inconsistent conditional result types
│ 
│   on <console-input> line 1:
│   (source code not available)
│ 
│ The true and false result expressions must have consistent types.
│ Mismatched list element types: The 'true' tuple has length 1, but
│ the 'false' tuple has length 2.
╵

> type(true ? tolist([[1]]) : tolist([[2,3]]))
list(list(number))

This is unfortunately a case where the "mismatch message" heuristic makes a poor choice about what to comment on: it is true that the tuple types are of different lengths, but it would be perhaps more relevant to say that the second inner tuple can't reduce to a list because its types are mismatching. I don't really know how to define a suitable heuristic to detect that situation or how to describe the detected problem concisely in English, though. 😖

[alisdair]

Oh, that makes sense!

It might be worth leaving a comment to that effect in this test, then. Or renaming the variables to tupleBoolNumber and tupleBool.

[liamcervante]

Yes, what Martin said!

I've added a comment explaining why the test cases fail.

[alisdair]

✅ with an inline suggestion to make the semantics of the updated test a bit clearer.

[alisdair]

Oh, that makes sense!

It might be worth leaving a comment to that effect in this test, then. Or renaming the variables to tupleBoolNumber and tupleBool.