[Feature Request]: nullable chaining Operation

[tmccombs]

This is copied from hashicorp/terraform#34870 because I think the hcl project is a better place for it.

Use Cases

Suppose I have an optional variable like:

variable "test" {
  type = object({
     field1 = string
     # and some other fields
    })
  default = null
)

and then somewhere else I need to use use the value of var.test.field, but use a default value of var.test is null.

I would like to be able to do something like:

something = coalesce(var.test?.field1, "default") # the default may actually depend on other variables

Attempted Solutions

I can of course do something like:

something = var.test != null ? var.test.field1 : "default"

but that is awkward and hard to read. It becomes even more so if there are multiple levels of possibly null objects that need to be traversed, especially since && isn't short circuiting.

Another option is to use try:

something = try(var.test.field1, "default")

the problem with this is that if I misspell something in var.test.field1, it will silently use the default instead of giving me an error.

Proposal

Add a .? operator similar to javascript's optional chaining feature.

Or maybe add a function like lookup, except use the default value if the first argument is null.

Or have a variant of try that will still fail for any other error than trying to look up a field on a null value.

[apparentlymart]

A function-based variant of this idea could have similar syntax to try but with each argument constrained to only include the subset of expression operations that HCL considers to be "traversals": attribute access and indexing.

By constraining it in that way the function could implement the step-by-step traversal itself, checking after each step whether its result was null and returning early if so.

This function could potentially also try a normal evaluation of the expression with the starting value forced to be an unknown value of the same type that the real symbol would've had and use the type of the resulting value as the result type of the function, which would allow the function to produce a consistent return type regardless of whether it's returning a null value, a non-null value, or an unknown value. That would retain the ability to typecheck during Terraform's planning phase to a similar extent as the naked expression could be.

(That use of unknown values to predict the return type could also be done by an operator version of this as originally proposed. I'm not arguing that this necessarily should be implemented as a function, only that it could be implemented as a function, if adding additional complication to HCL's traversal syntax seems undesirable.)