Interpolation of Optional values

[cueckoo]

Originally opened by @kalexmills in cuelang/cue#790

Currently when trying to interpolate an optional value, one has to specify the disjunction of the provided value and your default.

The below will not export, as the type isn't satisfied in the lattice.

a: {
  x: "\(optional)"
  optional?: string
}

$ cue export defaults.cue
a.x: invalid interpolation: cannot reference optional field optional:
    .\defaults.cue:2:6

But the below does.

a: {
  x: "\(optional | '')"
}

$ cue export defaults.cue
{
    "a": {
        "x": ""
    }
}

Now that I've encountered this, I'm curious; is this a design choice intended to keep all defaults explicit rather than implicitly using a "zero value" for the type, like we would expect in Go, or a consequence of other design choices? Maybe both?

[cueckoo]

Original reply by @mpvl in cuelang/cue#790 (comment)

I would typically write x: *"\(optional)" | "" here, but that doesn't really answer the question.

The issue here is that CUE wants concrete values for expressions, treats optional fields as non existent, and regular fields as required. So in this case, x is marked as "incomplete", which is a kind of error that can be resolved by setting optional to a concrete string value. There is an upcoming proposal that slightly shifts this, making regular fields optional, which would allow ignoring this error (and then be more explicit about fields that are really required).

That doesn't change, though, that if one wants some default value for such an expression, one needs to explicitly state this.

Not having a zero value for the optional field in this case is a consequence of needing concrete values. This is considered a safety thing: it may be that the user really intended this field to exist and if it doesn't, one can always use a disjunction. The same holds for null coalescing: *a["foo"] | "". It is common for languages to not default to some value for a["foo"] automatically. Some scripting languages tend to indeed pick convenience over safety, but one underpinning philosophy for CUE is that strictness and safety is important for configuration languages, even more so than for programming languages.