Structs: What is the difference between a "regular field" and a "required field constraint"

[JensRantil]

I am reading https://cuelang.org/docs/tour/types/structs/ and it states

A regular field (field: value) must be made concrete if it is exported to a data format such as JSON or YAML.

and

A required field constraint (field!: value) requires that the field be specified as a regular field if it’s exported.

I have been rereading these sentences over and over and I am struggling why I would use one over the other.

For example, have a look at this example. Is the only reason for using a required field contraint to get a slightly more friendly error message (that it's missing)?

[seh]

One difference that arises is with default values. You can supply a default value for a required field, but it won't be used at export time, whereas a default value for a regular value will be used.

I have a hard time understanding why it's valid to specify a default value for a required field. It may have something to do with unifying several mentions of the same struct field, some of them required, some not.

[seh]

Oh, not entirely answering my own question, and softening my assertion about the default value not being used, see this refinement of your example. Note how writing "a" into "Concrete2" as a regular field allows using the default value specified in "#Template2" on the required field.

[mvdan]

Correct. Default values in required fields are typically not what you want, but they're not entirely pointless either.

[seh]

That example reads to me as, "This field is required, but if by chance you're interested in allowing the default value, here is one that you can use."

[mvdan]

@JensRantil one mental model that works is to remember to stick to required and optional fields for schemas, and only use regular fields for data and templates.

And yes, a schema could use incomplete values in place of required field errors, which is partly why the CUE language only had regular and optional fields for a while. However, required fields are still very useful for good error messages and to truly distinguish missing fields from invalid/incomplete values.

[seh]

s/data and schemas/data and policies/, perhaps?

[mvdan]

Sorry, I meant templates!

[JensRantil]

@mvdan Hm, is your message above, what do you by "template" and "schema"? Are any of those "Definition"? I'm a bit confused.

[mvdan]

They are typically both represented as definitions. The difference is that a schema validates, without inserting any fields or values, whereas a template does add values or fields, for example via defaults or by deriving from existing fields.