cue/go: cue.Value.Subsume appears to ignore cue.Raw()

[sdboyer]

What version of CUE are you using (cue version)?

$ cue version v0.4.1

Does this issue reproduce with the latest release?

Yes

What did you do?

Checked for subsumption using cue.Raw() between two values that differ only by a field that has a default marker.

package main

import (
	"fmt"

	"cuelang.org/go/cue"
	"cuelang.org/go/cue/cuecontext"
)

const defaultsubsume = `
#one: {
	init: string
}
#two: {
	init: string
	withDefault: *"foo" | "bar" | "baz"
}
`

func main() {
	ctx := cuecontext.New()
	v := ctx.CompileString(defaultsubsume)

	one := v.LookupPath(cue.ParsePath("#one"))
	two := v.LookupPath(cue.ParsePath("#two"))
	fmt.Println(two.Subsume(one, cue.Raw(), cue.Schema()))
}

What did you expect to see?

That #two subsumes #one, when considering defaults (as the cue.Raw() docs indicate).

<nil>

What did you see instead?

required field is optional in subsumed value: withDefault (and 1 more errors)

[mpvl]

one is more broad than two. So two.Subsume(one) will not succeed under any circumstances.

[sdboyer]

Ah! OK, that simplifies things. It also explains why i've found some of the discussion around required fields, e.g. #822, confusing - my mental model has been off. FWIW, i think i was thrown off by this wording in the docs:

Use the Raw option to do a low-level subsumption, taking defaults into account.

In retrospect, i realize that i made an incorrect inference here - that doc refers to whether defaults on two existing fields are considered in subsumption, not on whether a default in the subsumer obviates the need for field existence in the instance. I thought it referred to both; that it refers only to the former is certainly simpler, and i'm delighted to have clarified a previously fuzzy area of my CUE mental model.

It's relatively simple to adapt Thema to this, so i can pivot - the simple answer is to just change existing guidance/thinking existing that defaults are sufficient to have the addition of a required field be considered backwards compatible.

All that said, i think part of the reason i made this erroneous inference in the first place was because i've narrowed my thinking to the one use case: authoring schema in CUE, but working with them primarily from other languages, and therefore using concrete objects. In that context, conflating these ideas makes sense - once an object has 'left' CUE, where the value came from doesn't really matter anymore. However, this starts veering into trickier territory about openness and closedness that i haven't figured out how to discuss yet - and is out of scope for this issue, as Subsume() is clearly behaving as expected.

Thanks!