Figure out how to express Lineage non-emptiness constraint

[sdboyer]

This problem has existed since the beginning with Thema, but working on #82 has made it especially clear: it is important to constrain that valid lineages must contain at least one schema. However, using a simple constraint like this:

import "list"

#Lineage: {
	// ...

	// schemas is the ordered list of all schemas in the lineage. Each element is a
	// #SchemaDef.
	schemas: [...#SchemaDef] & list.MinItems(1)

	// ...
}

Makes referencing #Lineage to specify the expected type of an argument to a pseudofunc, like this:

#LatestVersion: {
	lin: #Lineage
	out: lin.schemas[len(lin.schemas)-1].version
}

Result in those pseudofuncs be in a constant state of invalidity:

#LatestVersion.lin.schemas: invalid value [] (does not satisfy list.MinItems(1)): len(list) < MinItems(1) (0 < 1):
    lineage.cue:67:7
    lineage.cue:63:18
    lineage.cue:67:21

This feels very much like an "i'm holding CUE wrong" problem. Should i not even be trying to specify arg types? Is there a way of separating the constraint check so that these pseudofuncs retain the correctness bound, but it no longer bubbles up in the same way?

[verdverm]

One pattern you might consider is schemas: [#SchemaDef, ...#SchemaDef] which has the effect of requiring at least one element

[sdboyer]

yeah, that's the workaround we currently rely on. But that hits on the issue i frequently have with CUE - unification actually makes it hard to require a user to provide certain input.

One path i haven't explored, however, is having a default value for schemas that satisfies the MinItems(1) check, but is internally invalid in some way that effectively allows deferring these errors. That seems like the plausible path, here.