using defaults to solve disjunction

[hansbogert]

I was hoping not setting a field could solve a disjunction, given the following:

_#node: {
  name: string
  memory: *16384 | number
  cpu:    *2 | number
}

_#node16g: {
  name: string
  memory: 16384
  cpu:    2
}

_#node32g: {
  name: string
  memory: 32768
  cpu:    4
}

a: {
  name: "foo"
}

a: _#node

eval'ing gives:

cue eval  example1.cue
a: {
    name:   "foo"
    memory: 16384
    cpu:    2
}

So far this as expected, however let's add one line to the example1.cue:

a: { _#node16g | _#node32g}

I would expect eval'ing this would yield the same answer, as a is, as we seen, defined with at least a field memory: 16384 which should be enough to resolve the disjunction, alas:

 cue eval  example1.cue
a: {
    name:   "foo"
    memory: 16384
    cpu:    2
} | {
    name:   "foo"
    memory: 32768
    cpu:    4
}

Am I misunderstanding cue's model in this case?

[mvdan]

This is how I would typically write what you want to do, by having the default on the disjunction between the two definitions: https://cuelang.org/play/?id=OVi9f4ylQBz#w=function&i=cue&f=eval&o=cue

As for why your original example isn't working as you might think, I'm actually not sure. Here is a simpler example showing an ambiguous result in a similar way:

#schema: f: *1 | 2
#one: f: 1
#two: f: 2
out: #schema & (#one | #two)

Interestingly enough, if I drop all f: fields, then the output is unambiguously 1. The ambiguity only appears with the nesting of a struct field.

[hansbogert]

Yeah your example fixes it in my actual (non-contrived) code as well, still my intuition is not right here. It's quite a mental journey with Cue 😄