Proposal: predicate builtins

[mpvl]

Proposal: predicate builtins

Revised 2026-09: exists is now strict about fields that can never
exist; isConcrete of an absent field is false instead of an error;
validN and concreteN are replaced by the more general countN;
and allows moves to a new standard library reflect
package, joining the new Field function. Both open
questions below are resolved. See the follow-up comment for what
changed and why.

Summary

Add a family of predeclared builtins that let CUE inspect a value's state — whether a field is present, whether an expression is valid, whether it is concrete, and whether a label is permitted — returning a boolean without propagating errors. They are first-class, well-defined replacements for the long-standing comparison-to-bottom idiom (!= _|_ / == _|_).

The set:

builtin	kind	question
exists(ref)	function → bool	is the referenced field present as a regular member?
isValid(expr)	function → bool	can expr still be made concrete, without error?
isConcrete(expr)	function → bool	does expr evaluate to a concrete value?
existsN(n, refs…)	validator	do n of the referenced fields exist?
countN(n, [conds…])	validator	are n of the boolean conditions true?
reflect.Allows(s, label)	function → bool	may label (string field / int index) ever appear on s? (stdlib)
reflect.Field(s, name)	function → value	the value name has, or would have, in s (stdlib)

In the …N validators, n is the same kind of count constraint: a literal requires exactly that many, and a bound such as >=2 or <=1 requires at least or at most that many.

The predeclared builtins are gated behind a new per-file experiment, @experiment(predicates) (preview in v0.18.0); the reflect functions are ordinary standard library functions. The normative semantics and worked examples are in the language spec (doc/ref/spec.md).

This supersedes the relevant part of #943, with the other builtins it mentioned spun out separately (e.g. must is already tracked in #575).

Motivation

Users routinely need to branch on properties that CUE's monotonic, error-propagating evaluation otherwise hides — is this field present? did this evaluate without error? is it concrete yet? Today this is written as a comparison to bottom:

if x != _|_ { out: x }   // "x is present / valid"

That idiom is problematic:

• It conflates three distinct questions — presence, validity, and concreteness.
• It has no documented semantics; the behavior is an artifact of the implementation.

Giving each question its own named builtin makes the intent explicit and the semantics specified, and lets the evaluator surface order-dependence as a cycle rather than a silent wrong answer.

A concrete driver is protobuf's oneof — "exactly one of these fields is set." That is currently awkward to encode in CUE (it needs a disjunction of structs or hand-written constraints); existsN(1, a, b, c) expresses it directly. countN generalizes this "N of M" pattern from presence to arbitrary boolean conditions.

Proposal

All builtins are predeclared and gated behind @experiment(predicates); the reflect functions are ordinary standard library functions.

Design principles

Three rules determine most of the edge-case behavior:

1. Only isValid converts a permanent error into a boolean; every other builtin propagates errors like ordinary evaluation, so the predicates never silently mask a broken configuration. (The *f(x) | fallback disjunction remains the way to tolerate errors at the expression level.)
2. For presence questions, false always means "not now, but a legal configuration could add it"; a question whose answer can never be true — a mistyped field on a closed struct — is an error. Whether a field is possible is judged from the declarations, not from whether its constraint is satisfiable.
3. The builtins read their argument once the configuration is finalized and then give a definite answer; absence is never a reason to remain incomplete. A post-check verifies the answer once evaluation settles and reports order-dependence as a cycle.

Functions (→ bool)

exists(ref) — whether the referenced field is present as a regular member. A field that is absent but could still be added is false: a declared optional or required field without a value, an undeclared field on an open struct, a label matching a pattern constraint, or an index just beyond an open list. A field that can never exist is a permanent error: an undeclared field on a closed struct or definition, an out-of-range index of a closed list, or a field of a scalar. Presence is independent of the field's value: a present field whose value contains an error still exists. ref must be a reference (field reference, selector, or index expression); a non-reference argument is an error.

a: {
	x:  1
	y?: string
}
#A: c: 1
exists(a.x)            // true
exists(a.y)            // false: y is optional and unset
exists(a.z)            // false: a is open, z could still be added
exists(a["x"])         // true
exists(#A.nonExisting) // _|_: #A is closed, nonExisting can never exist

To probe a field that may be impossible, compose: *exists(cfg.tls) | false never errors, and reflect.Allows(cfg, "tls") && exists(cfg.tls) guards the probe (&& short-circuits). The fallback form also covers chained paths through absent intermediate fields, as in .Values.a.b.c-style templating: *exists(vals.absent["k"]) | false is false, not an error.

isValid(expr) — true iff expr can still be made concrete, without error, by unifying it with some value. It is false when the expression's own result is an error of any kind — a permanent error, or an unresolved or absent reference — and when a permanent error is reachable in some instance of it. Values that are merely unfinished are valid: abstract types, unresolved disjunctions, and incomplete interior fields. Constraints that no instance is required to satisfy do not invalidate a value.

isValid(1 + 2)        // true
isValid(1 / 0)        // false: division by zero
isValid("a" & 1)      // false: conflicting values
isValid({a: 1}.b)     // false: the field does not exist
isValid({a?: 1 & 2})  // true:  instances may omit a
isValid({a!: int})    // true:  can be satisfied by adding a: 1
isValid({a!: 1 & 2})  // false: no instance can satisfy a

Note that it matters where an incomplete part sits: with b: {x: y + 1, y: string}, isValid(b) is true (the struct is a fine partial value) while isValid(b.x) is false (the expression's own result is incomplete). Also, isValid reports; it does not rescue: a broken regular field still makes the configuration fail, whatever isValid returns.

isConcrete(expr) — whether expr evaluates to a fully concrete value, as export requires: recursively for structs and lists, with no required field left unset. Optional fields, pattern constraints, and open list tails play no role. An absent field is not concrete, so the answer is false rather than an error. A permanent error is passed through: whether a broken value is concrete is not a meaningful question. To tolerate broken values deliberately, write isValid(x) && isConcrete(x).

isConcrete(1)            // true
isConcrete(int)          // false: int is a type
isConcrete({a: int})     // false: a is not concrete
isConcrete({a?: int})    // true: optional fields play no role
isConcrete({a!: int})    // false: a is required but not present
isConcrete([1, int, 3])  // false: element is not concrete
isConcrete(1 & 2)        // _|_: the error is passed through
a?: int
isConcrete(a)            // false: a is not present
s: {a?: 1}
isConcrete(s.a)          // false: absent, though its constraint is concrete
#C: {b: 1}
isConcrete(#C.a)         // _|_: a can never exist on a closed struct

Count validators

existsN is embedded in a struct to constrain how many of the referenced fields exist, and directly encodes protobuf's oneof and its relatives. It is shorthand for countN over exists conditions — existsN(n, a, b, c) is equivalent to countN(n, [exists(a), exists(b), exists(c)]) — and each reference has the semantics of exists, including strictness: a mistyped reference is an error, not a silently uncounted condition.

#OneOf: {
	existsN(1, a, b, c)  // exactly one of a, b, c
	a?: int
	b?: string
	c?: bool
}
foo: #OneOf & {a: 1}          // {a: 1, b?: string, c?: bool}
bad: #OneOf & {a: 1, b: "x"}  // _|_: two fields set
 
#AtMostOne: {existsN(<=1, x, y), x?: int, y?: int}
#AtLeastTwo: {existsN(>=2, a, b, c), a?: int, b?: int, c?: int}

countN(n, [conds…]) is the general form: it constrains how many conditions in a list of booleans are true, so it combines with any predicate, and the list may be computed:

countN(1, [isConcrete(a), isConcrete(b)])      // exactly one concrete
countN(1, [for k in names {exists(spec[k])}])  // computed conditions

The two argument shapes are deliberate: existsN takes its references as separate arguments because references are syntax, not values — in a list literal they would be evaluated — while countN takes a list because CUE has no spread operator, so the list form is the only one that admits computed conditions. validN and concreteN from the earlier version of this proposal are subsumed and removed.

A permanent error in a condition propagates; a condition that is still incomplete when the configuration is finalized is an error rather than being counted as false. If a count constraint can never be satisfied, validation fails immediately; otherwise it stays incomplete until a definitive answer can be determined. Once determined, a violation is a permanent error, so isValid(countN(...)) converts a validator outcome into a boolean.

Standard library

The reflect package houses the value-inspection functions. They are ordinary functions and need no experiment.

reflect.Allows(s, label) — whether label (a string field name or integer index) may ever appear on the struct/list s. It is the structural "may ever appear" counterpart to exists, and never errors where exists does: for an undeclared k on a closed s, both s.k and exists(s.k) are errors, while reflect.Allows(s, "k") is false.

s: {a: 1}
reflect.Allows(s, "b")              // true: s is open
reflect.Allows(close({a: 1}), "b")  // false: closed, "b" not allowed
reflect.Allows([1, 2, 3], 3)        // false: index out of range

reflect.Field(s, name) — the value that the field name has, or would have, in s, defined as the value of name in s & {(name): _}: a present field's value; a declared optional or required field's constraint, with applicable pattern constraints unified in; _ for an undeclared name on an open struct; an error for a name that can never exist. This makes the constraint of an absent field observable:

x: {a?: 123}
isConcrete(x.a)                    // false: the field is absent
isConcrete(reflect.Field(x, "a"))  // true:  its constraint is concrete
isValid(reflect.Field(x, "f") & 5) // could f hold 5, without adding it?

reflect.Field alone cannot distinguish an absent field from a present one whose value is _; combine it with exists or allows to disambiguate.

Resolved questions

The two open questions of the original proposal are resolved as follows.

What does isValid close over?

The configuration: isValid reads its argument once the configuration is finalized, so anything the configuration itself supplies counts, and nothing hypothetical does. In the example

a: c
c?: int
x: isValid(a)

x is false — when the configuration is finalized, a has no value — and becomes true the moment a sibling supplies c: 5. A stricter reading, "satisfiable by unifying the value in isolation," remains expressible later via a self-containedness predicate, which is left for future work.

What does isConcrete report for an optional or required field?

false, rather than an error: a field that is not present is not concrete, so the question has a definite answer. This also makes the guard if isConcrete(a) {...} usable for its main purpose. isConcrete({a?: 123}) remains true: the optional field plays no role, and the struct exports fine. To ask about the value an optional field would have, rather than the field itself, use reflect.Field (see above).

Relationship to #943

#943 is stale (it predates allows and isValid), too broad (it also covers must, range, …), and has accumulated unrelated discussion. This proposal pins down the concrete, implemented design for the presence/validity/concreteness predicates, and deliberately uses the name predicates rather than "reflect"/"introspection" — reserving the latter for possible future capabilities (subsumes, self-containedness), which are explicitly left open. Constraint access, previously in that category, landed as reflect.Field.

[seh]

The assertion that optional fields don't exist is hard to accept. This area of CUE is still hard to understand. My coworkers have asked me several times recently what it means for an optional field to have a concrete value, or to have a default value.

My initial take is that isConcrete evaluated against an optional field should report whether the value held by that field is concrete.

You shared this example:

a?: 123
x: isConcrete(a)

I read that and think, "a is 123, which is a concrete value", without paying any attention to whether a is optional or not. We can augment that example slightly, without changing a's value, and ask the same question of it again:

a?: 123
a: _ // Effectively no statement, other than that 'a' should be exported.
x: isConcrete(a)

Now, you could say, "Well, that's a different question; you're asking about a different a there—a present, regular a."

Again, I read the isConcrete predicate to be asking not about qualification or presence of the expression, but rather about the value that it bears. Does an optional field bear a value or not?

[seh]

That I have trouble with the terms here is more indication that we got optional and required fields, but without a firm enough grounding in how to both discuss and use them.

I'm confused by this statement of yours:

would imply that isConcrete({a?: int}) should be false, which is clearly wrong

If isConcrete({a?: int}) is clearly not false, are you suggesting that instead it's true, or that it should result in an error, because the question itself is malformed?

[mpvl]

isConcrete({a?: int}) should be true, as the optional field plays no role in whether a value is concrete.

So similarly, it would be surprising to me if isConcrete would behave differently when directly referencing an optional field directly instead of indirectly. But I realize evaluating an argument to be passed to isConcrete is somewhat of an orthogonal concern.

Having better language around regular fields versus "schema" fields would certainly be useful. CUE derives its power from defining both within the same space. But I understand that can also be confusing. But basically, the way I hold it: regular fields -> JSON, constraint fields -> JSON Schema. They just happen to be able to be in the same object.

[mvdan]

@seh another way to think about Marcel's isConcrete({a?: int}) is that cue vet -c accepts it and cue export renders it as {}. So it is a concrete struct, because it finalizes and exports as an empty struct with zero fields.

[seh]

Reading both of your responses now, I see that the question mark on a renders it "invisible" for this question, such that {a?: 123} and {} are equivalent treatments of the argument to isConcrete here.

Does that mean that "What does isConcrete report for an optional field?" is still an open question, or did we just settle it here? Perhaps isConcrete({a?: 123}) is different enough from isConcrete(a), because the former is looking at a struct value, not a reference to a field.

[mvdan]

Indeed the two cases are different. Given the CUE {a?: 123}, you can export the whole value just fine as {}. But you cannot export the reference a, because resolving that reference results in a "cannot reference optional field" error.

[mxey]

Does this provide a way to check for an optional field having a value, but raising an error if that field can never exist? There is the combination of allows & exists, but what I am thinking of is how to avoid typos when using exists.

[mpvl]

That was the original implementation of exists, and either interpretation would be fine.

In the end we ended up with the current semantics. But as said, this may change based on popular demand.

There were several reasons to take this stance:

• Using a stricter semantics makes it almost impossible to auto-rewrite comparing to bottom.
• You can get the semantics you want roughly already with try
• We can still do the typo checking in some cue linter (cue lint or an extended cue vet).

But as said, this is a bit of a toss up.

[mpvl]

One option is to have an option exists(x.b, strict: true) down the line.

[mxey]

You can get the semantics you want roughly already with try

Do you mean by using an optional field in a try? That won't swallow errors?

[myitcv]

Some feedback from a full-scale adoption exercise. helm2cue generates CUE from Helm charts, and its output leans heavily on the historical != _|_ idiom this proposal replaces: a _nonzero truthiness helper that type-dispatches over six kinds, a _typeof helper, nested-path traversal (dig), key-membership tests (hasKey, merge/mergeOverwrite), and type tests (kindIs, typeIs). I converted every one to the predicate builtins behind @experiment(predicates), round-trip verified against helm template (cue-exp/helm2cue#127).

Overall: it works, and the output reads far better than the bottom comparisons. But having looked harder at why it works, my headline finding has changed: the drop-in only works because isValid returns what I think is the wrong answer in one case, and helm2cue's generated code is unwittingly depending on that. The deeper cause is that exists — the primitive whose spelling fits these sites — is unusable for these patterns, so the conversion was forced onto isValid everywhere.

Each claim below is a self-contained testscript reproducer, run with cmd/testscript against cue version v0.17.0-alpha.2.0.20260612134833-f88c737c8ff6. Every archive sets @experiment(predicates) and language.version: "v0.17.0". Each reproducer asserts the behaviour I believe is correct (or that a code generator needs), so the intended result is pass. Where the implementation differs, I follow the reproducer with the verbatim testscript run — which fails, and that failure is the finding. (In those run blocks I've elided testscript's echo of the script comment, shown in the archive just above, keeping the command trace and result.)

1. isValid misclassifies an absent/incomplete selection as invalid — I think this is a bug

isValid(x) matched x != _|_ at every site — and that clean uniformity is itself the tell. The sites aren't all the same kind of question. A few are genuine validity checks (isValid(x & struct.MaxFields(0)) as an emptiness test). But several are really presence checks — does this field exist? — and isValid only "covered" them because it happens to return false for an absent reference: an unset optional field; a field set to a reference to an absent field; an index whose base does not resolve. A builtin named for validity ended up answering presence questions across the board, which is what finding 2 is really about. And in the absent case it doesn't merely overreach — it returns the wrong answer.

The proposal describes isValid as true when there is no permanent error, with incomplete-but-completable values valid. An absent-field selection on an open struct is an incomplete error, not a permanent one. The proposal doesn't pin down a single answer here — it could be true, or isValid could itself fail to reduce, or something else — but it does seem fairly clear the answer is something other than false, since false is the definite "this is invalid" verdict and an incomplete value hasn't earned it. The testable property I'm confident in: a bare incomplete selection and the same selection under a type conjunction are both incomplete, so isValid must classify them alike. That reproducer should pass:

# s.absent and s.absent & int are both incomplete selections, so isValid
# must classify them alike; in particular neither is the definite "invalid"
# verdict false.
exec cue export x.cue -e out
cmp stdout stdout.golden

-- cue.mod/module.cue --
module: "mod.example"
language: version: "v0.17.0"
-- x.cue --
@experiment(predicates)

s: present: "x"

out: isValid(s.absent) == isValid(s.absent & int)
-- stdout.golden --
true

What we actually see when we run it:

$ testscript r1-expected.txtar
> exec cue export x.cue -e out
[stdout]
false
> cmp stdout stdout.golden
diff stdout stdout.golden
--- stdout
+++ stdout.golden
@@ -1,1 +1,1 @@
-false
+true

FAIL: r1-expected.txtar:5: stdout and stdout.golden differ
failed run

The bare-selector branch is the one classifying the incomplete value as false — the value the proposal rules out. That's the bug; it isn't two defensible readings.

Two consequences:

• I'm not asking to pin the false into the spec — nor am I asking for a specific replacement value (true or a non-reducing result both fit the wording). I just think false is the one answer the proposal rules out. I'm flagging it because helm2cue's generated code currently relies on that false (next point), so fixing it will, rightly, force a codegen change. Better that than building a generator on behaviour that contradicts the proposal.
• isValid(val & T) is therefore not a faithful replacement for (val & T) != _|_. Every type test helm2cue emits needs the two-call guard isValid(val) && isValid(val & T) — verbose, and the reason for the leading guard is non-obvious. Worth either blessing that idiom explicitly or offering a direct "present and unifies with T" predicate (a kind-flavoured builtin may serve better than predicates here).

2. The conversion was forced onto isValid as a presence test, because exists can't reach these patterns

This is the real story behind finding 1. Every presence-flavoured site (hasKey, dig, key membership in merge) wants a presence predicate, and exists is exactly the right spelling. In practice I couldn't use it — for one reason in exists itself, and a second that turns out not to be about exists at all, but about how these helpers are encoded.

First, exists is fine on a field or key whose immediate base resolves — an absent field or key yields false, not an error. This reproducer passes:

# When the immediate base resolves, exists answers presence correctly: an
# absent field or key yields false, not an error.
exec cue export x.cue -e out
cmp stdout stdout.golden

-- cue.mod/module.cue --
module: "mod.example"
language: version: "v0.17.0"
-- x.cue --
@experiment(predicates)

vals: str: "x"
m: present: "x"

out: {
	existsAbsentField: exists(vals.absent)       // base resolves -> false
	existsAbsentKey:   exists(m["absent"])       // base resolves -> false
	isValidIdx:        isValid(vals.absent["k"]) // false
}
-- stdout.golden --
{
    "existsAbsentField": false,
    "existsAbsentKey": false,
    "isValidIdx": false
}

But it errors once you index or select through a base that is itself unresolved — the chained pattern (.Values.a.b.c) that dominates config templating, where an intermediate is routinely absent. For presence that should be false, so this reproducer should pass:

# For a presence check, indexing through an absent base means "no" -> false.
# This is the chained-presence case that dominates config templating
# (.Values.a.b.c). Without a concreteness requirement (cue vet -c=false) the
# package should be valid; with one (cue export) it should yield false.
exec cue vet x.cue -c=false
exec cue export x.cue -e out
cmp stdout stdout.golden

-- cue.mod/module.cue --
module: "mod.example"
language: version: "v0.17.0"
-- x.cue --
@experiment(predicates)

vals: str: "x"

out: exists(vals.absent["k"])
-- stdout.golden --
false

What we actually see when we run it — cue vet -c=false (no concrete result required) passes, but cue export (concrete result required) errors instead of yielding false:

$ testscript r3-expected.txtar
> exec cue vet x.cue -c=false
> exec cue export x.cue -e out
[stderr]
out: undefined field: absent:
    ./x.cue:5:18
[exit status 1]
FAIL: r3-expected.txtar:6: unexpected command failure
failed run

An absent base should simply mean "no" for presence. This looks like the job of a non-strict exists (the strict/non-strict distinction mentioned upthread): non-strict letting an unresolved base propagate as false, strict keeping the typo-detecting error.

Second — and this one is really about the function pattern, not exists. As #3711 sets out, a helper's out is written in terms of #arg but isn't tied to it: out can be valid even when #arg is in error. With #f: {#arg?: _, out: 5}, (#f & {#arg: true & false}).out is 5, not an error.

The predicates proposal turns out to supply the tie #3711 found missing — no must(), no change to the error model. Unify a validity validator into the result and out becomes valid iff #arg is:

# The function pattern's result is not tied to its argument: out can be
# valid even when #arg is in error. Unifying a validity validator into the
# result restores the tie — out is valid iff #arg is. A valid argument
# passes through to 5; an invalid one makes out an error.
exec cue export x.cue -e ok
cmp stdout ok.golden

! exec cue export x.cue -e bad
stderr 'validN: 0 matched, expected 1'

-- cue.mod/module.cue --
module: "mod.example"
language: version: "v0.17.0"
-- x.cue --
@experiment(predicates)

#g: {#arg?: _, out: validN(1, #arg) & 5}

ok:  (#g & {#arg: 7}).out
bad: (#g & {#arg: true & false}).out
-- ok.golden --
5

A valid argument passes through to 5; an invalid one makes out an error. With the argument tied this way, exists can then be used as normal to test parts of it.

There's a catch, though, and it loops straight back to finding 1. When #arg is optional, you usually want to validate it only when present — provided ⇒ validated, absent ⇒ result unaffected. The tie doesn't give you that: an absent #arg is counted as not valid, so the validator rejects it rather than passing through. This reproducer should pass:

# An optional argument should be validated only when present: provided ->
# validated; absent -> the result unaffected, here yielding 5. (#arg is the
# validity-tied function argument from r4-tie.)
exec cue export x.cue -e out
cmp stdout out.golden

-- cue.mod/module.cue --
module: "mod.example"
language: version: "v0.17.0"
-- x.cue --
@experiment(predicates)

#g: {#arg?: _, out: validN(1, #arg) & 5}

out: (#g & {}).out
-- out.golden --
5

What we actually see when we run it:

$ testscript r5-optional-gap.txtar
> exec cue export x.cue -e out
[stderr]
out: validN: validN: 0 matched, expected 1:
    ./x.cue:3:21
    ./x.cue:3:28
[exit status 1]
FAIL: r5-optional-gap.txtar:4: unexpected command failure
failed run

That "an absent optional counts as not valid" is exactly finding 1's misclassification (isValid(<absent>) == false) resurfacing through validN. So it isn't a separate gap so much as another face of finding 1 — and it sharpens the ask there: for "validate only if present" to be expressible, an absent/incomplete argument has to resolve as valid (not false, and not merely non-reducing). Which way finding 1 lands decides whether this pattern works at all.

So isValid — which accepts any operand and (via the finding-1 bug) already answers presence for references — was the path of least resistance, and exists went largely unused. The pieces this proposal owns are the two findings: exists stuck on a chained/unresolved base, and the isValid classification of an absent/incomplete selection — the latter governing finding 1 directly and whether the validator-tie above works for optional arguments.

What I'd ask for

These pay off only together:

1. Fix isValid so an incomplete (absent / unresolved) selection is not reported as false — true or a non-reducing result, whichever the proposal settles on — bringing the bare selector into line with the & T branch and making isValid an honest validity predicate. (Finding 2's validator-tie gives a concrete reason to prefer the valid resolution over non-reducing: validating an optional argument only-when-present needs an absent one to count as valid.)
2. Make exists usable for presence: non-strict treatment of an unresolved base (propagate as false, not error).

With both, helm2cue can compute presence at the call site with exists and reserve isValid for validity — the separation this proposal is for. Fixing (1) on its own breaks the current output: the _nonzero truthiness guard is isValid(#arg), relying on today's isValid(<absent>) == false. Once that's corrected the guard can't simply become exists(#arg) (the function-pattern issue above), so presence has to move to the call site — where it needs (2) to survive chained paths. Hence the two want to land together, with a codegen restructure on the helm2cue side.

3. Smaller notes

• !isValid(x) reads fine as the replacement for x == _|_ (kindIs "invalid", typeIs "<nil>").
• I found no use for existsN/validN/concreteN in this domain — the oneof pattern doesn't arise in Helm conversion. No objection; just a datapoint that the singular forms carried all the weight.
• Since the experiment gates on language version v0.17.0, tools that generate CUE must also bump the language version of the modules they emit. Worth a sentence in the proposal: adoption by generators moves the version requirement onto their users' modules.

Against the cited build, the r1-expected, r3-expected, and r5-optional-gap reproducers fail as shown — those failures are the findings — while r2-exists-base-ok and r4-tie pass. The full conversion is in cue-exp/helm2cue#127.

[myitcv]

Note I have heavily updated the reply above, rather than posting a follow-up reply. There were a number of things which (on deeper reading) were wrong in terms of direction.

[myitcv]

I've done another heavy iteration on the wording

[mpvl]

I have updated the proposal above based on the feedback in this thread and a more detailed look at the edge cases. A summary of what changed, per thread:

@mxey: we ended up making exists strict, as you suggested. As said, this was a bit of a toss up; a closer look at the edge cases tipped it the other way. There were a few reasons:

• You can still get the lenient behavior from the strict one, for instance *exists(s.k) | false (which never errors) or reflect.Allows(s, "k") && exists(s.k) (&& short-circuits, so the guard protects the probe).
• There is no way to get the strict behavior from a lenient exists: a false guard gives false, never the error you want for a typo.
• The earlier reasons for the lenient semantics no longer really hold: the != _|_ rewrite maps to isValid, not exists (cue fix --exp predicates now does this rewrite), and a linter cannot see through computed labels.

This also means we no longer need the exists(x.b, strict: true) option I mentioned earlier: strict is now the default, and the lenient forms can be composed from it.

@seh: isConcrete of an absent field is now false instead of an error. The struct cases are unchanged: isConcrete({a?: 123}) and isConcrete({a?: int}) are both true, for the reasons discussed above. One addition from the same principle: isConcrete({a!: int}) is now false, as an unset required field blocks export. Also, instead of the a? reference syntax I mentioned, there is now reflect.Field(s, "a"), which reports the value a has, or would have, in s. So isConcrete(reflect.Field(s, "a")) is true for a?: 123 and false for a?: int, without the non-trivial language implications of allowing ? in references.

@myitcv: both your findings led to changes, though one went in a different direction than you suggested. I believe it still covers the helm2cue cases:

1. The inconsistency is fixed, and in the false direction: isValid(s.absent) and isValid(s.absent & int) now agree — both are false. You were right that the two must classify alike; the branch returning true was the bug. But we ended up with false rather than valid: isValid answers a question about a value, and when the configuration is finalized an unresolved selection has none. Also, bottom & T is still bottom, so no unification of the result can rescue it. The wording in the proposal that seemed to rule out false is what needed fixing. Two consequences:

   • isValid(val & T) is now exactly the single-call "present and unifies with T" test you were after: absent gives false, present-and-unifying true, present-and-conflicting false. The two-call guard is no longer needed.

   • You can also express "validate only when present" without making absence count as valid: !exists(#arg) || isValid(#arg) (the || short-circuits). For the function pattern from eval: issues around the function pattern #3711:

     #g: {#arg?: _, out: countN(1, [!exists(#arg) || isValid(#arg)]) & 5}
     (#g & {}).out              // 5: absent, unvalidated
     (#g & {#arg: 7}).out       // 5: present and valid
     (#g & {#arg: 1 & 2}).out   // _|_: present and invalid
     

2. exists is now strict rather than lenient, but with disjunction you can absorbs its errors, including incomplete errors from missing intermediate fields. So the .Values.a.b.c pattern works: *exists(vals.absent["k"]) | false is false, not an error. This keeps typo detection where schemas are closed, while giving generated code a form that never errors. So helm2cue can use exists in the fallback form for presence and reserve isValid for validity, which is the separation this proposal is about. Note that validN is removed; its uses convert to countN over isValid conditions, as in the example above.

Some other changes:

• validN and concreteN are replaced by the more general countN(n, [conds…]). There is deliberately no separate count function: isValid(countN(...)) covers the boolean uses, and an int-valued form can be added to the standard library later if there is demand.
• existsN stays as the oneof shorthand. Each reference now has the strict exists semantics, so a mistyped reference in a oneof list is an error rather than a silently uncounted condition.
• allows moved to the standard library as reflect.Allows: with a fix to how closedness passes through function arguments, it needs no special treatment, and reflect is now the home for the value-inspection functions Allows and Field. While moving it we found and fixed a bug where the closedness of an inline close(...) argument was lost when passed to a function.
• There is no field-enumeration function: [for k, _ in s {k}] already expresses it, and a builtin that differed from the comprehension on broken or required-but-unset fields would just be a second, subtly different error-tolerance mechanism.

The proposal body above has been updated to reflect all of this. As before, some of this may still change based on feedback.