CUE field types: what's available & what's missing

[jpluscplusm]

Right now, CUE makes 3 types of field available. To quote the spec:

A field is a definition if its identifier starts with # or _#.
A field is hidden if its identifier starts with a _.
All other fields are regular.

Here's a table mapping each of those types to some key characteristics:

	Regular fields	Definitions (#)	Hidden fields (_)	Hidden definitions (_#)
Visible in cue export	✅	❌	❌	❌
Accessible across package boundaries	✅	✅	❌	❌
Recursively closed	❌	✅	❌	✅

Table markdown for copy/paste in replies

| | Regular fields | Definitions (`#`)| Hidden fields (`_`) | Hidden definitions (`_#`)|
| ---:|:---:|:---:|:---:|:---:|
| Visible in `cue export` | ✅ | :x: | :x: | :x: |
| Accessible across package boundaries | ✅ | ✅ | :x: | :x: |
| Recursively closed | :x: | ✅ | :x: | ✅ |

This discussion is here to ask:

• are there any additional field types that users would benefit from CUE making available?

And to help answer that:

• are there any distinguishing characteristics that should be added to the above table?

[jpluscplusm]

In https://cuelang.slack.com/archives/CLT4FD7KP/p1694086198707659 I proposed:

I'd like a CUE field type to exist that:

• isn't visible in exported output (like a hidden field isn't)
• is visible across package boundaries (like a definition is)
• doesn't recursively close its contents (like a hidden field doesn't)

The use case for this new type was for it to act as a non-recursively-closed, cross-package "function parameter" type.

This would extend the table in the discussion's opening post as follows:

	Regular fields	Definitions (#)	Hidden fields (_)	Hidden definitions (_#)	New type (%)
Visible in cue export	✅	❌	❌	❌	❌
Accessible across package boundaries	✅	✅	❌	❌	✅
Recursively closed	❌	✅	❌	✅	❌

A nuance which I don't /think/ is completely captured in this table is the effect of combining the new type with a definition. I.e. is Baz closed, in the following example?

#Foo: {
  %Bar: {
    Baz: {
       a: int
       b: bool
     }
   }
}

^{In other words, does the new type "block" (for want of a better word) recursive closedness implied by its container? I think that the answer needs to be "yes, it stops any 'inherited' closedness, but without recursively opening the fields it contains". If this wasn't the case, then the new type wouldn't be usable as a cross-package function parameter type where the function itself was declared as a definition. Or, rather, the new type would be indistinguishable from a definition when used in this situation, and might as well not exist.}

[fgalassi]

// this works

#definition: {
foo: string
...
}

def1: #definition & {
foo: "foo"
bar: "bar"
}

[jpluscplusm]

Thanks for commenting, but I'm not quite sure what point you're making!

Are there useful CUE field types you think are missing ... or something else?

[fgalassi]

My point is that the triple dot at the end of the definition makes it behave exactly like the % type you're talking about, AFAIC

[jpluscplusm]

The ... only permits additional fields inside the scope in which it's specified. It doesn't keep the structure open recursively, as would be the case with the proposed % type.

Here's an example of where that's a problem, building on your example:

exec cue vet file.cue
-- file.cue --
#Def: {
	foo: string
	A: {
		B: {
			C: string
		}
	}
	...
}

def1: #Def & {
	foo: "foo"
	bar: "bar"
	A: B: X: "wibble"
}

Running this with testscript gives the following:

> exec cue vet file.cue
[stderr]
def1.A.B.X: field not allowed:
    ./file.cue:4:6
    ./file.cue:11:7
    ./file.cue:14:8
[exit status 1]
FAIL: /tmp/testscript2646488578/foo.txtar/script.txtar:1: unexpected command failure