Value.Expr() giving unexpected (?) result for disjunction

[sh0rez]

I came across this behavior, which I don't understand. In case it's correct, can someone explain?

package main

import (
	"fmt"

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

const src = `
E: 1 | 2 | 3
T: {
	e: E | *2
}
`

func main() {
	ctx := cuecontext.New()

	v := ctx.CompileString(src)
	e := v.LookupPath(cue.ParsePath("T.e"))
	fmt.Printf("e: k=%s ik=%s\n", e.Kind(), e.IncompleteKind())
	eop, evals := e.Expr()
	fmt.Printf("e: op=%s, len(vals)=%d\n", eop, len(evals))
	fmt.Printf("WHY: eop == cue.NoOp: %t\n", eop == cue.NoOp)
	fmt.Println()

	c := evals[0]
	fmt.Printf("c: k=%s ik=%s\n", c.Kind(), c.IncompleteKind())
	cop, cvals := c.Expr()
	fmt.Printf("c: op=%s, len(vals)=%d\n", cop, len(cvals))
	fmt.Printf("WHY: cop == cue.SelectorOp: %t\n", cop == cue.SelectorOp)
}

Output:

e: k=_|_ ik=int
e: op=, len(vals)=1
WHY: eop == cue.NoOp: true

c: k=_|_ ik=int
c: op=., len(vals)=2
WHY: cop == cue.SelectorOp: true

https://play.golang.org/p/oEgelO--Mcw

Why exactly is e.Expr() a cue.NoOp, but still got an operand, that itself has a different expr (cue.SelectorOp)?

I would have expected e.Expr() to give an cue.OrOp, given the disjunction in the CUE code.

[verdverm]

Not sure of the answer without digging in further myself.

It could be helpful to pretty print val.Syntax() with https://pkg.go.dev/github.com/kr/pretty though there could be a lot of noise. In other words, printing more of the AST might help to see what is going on

[sdboyer]

For posterity - this appears to be the expected, if undocumented behavior of Value.Expr(): it strips off all disjunction branches that a) have a default marker, and b) do not widen the least upper bound given the other branches of the disjunction. This is performed recursively through all referenced values.

This can produce somewhat surprising results. If, after default removal, the disjunction is removed (only a single branch remains) - as in the example case - then Expr() considers there to be no actual cue.OrOp. Instead, it sees only cue.SelectorOp, indicating that E is actually a reference to another value.

On the plus side, this ends up meaning that, between Value.Default() and Value.Expr(), it's possible to fully, recursively separate default-marked declarations from unmarked ones.

[myitcv]

FWIW I think this is a bug: #1710