Remove some validator simplifications

[mpvl]

To improve the predictability and consistency of CUE’s validator behavior by disallowing the unification of two non-concrete values into a concrete value. This eliminates inconsistencies in bound simplifications and simplifies reasoning about constraint reductions.

Proposal

• Disallow unification of two non-concrete values into a concrete value. For instance: >=1 & <2 & int should not simplify to 1.

• Disallow the simplification of non-concrete validators. For instance, <=(<3) should not simplify to <3, but rather be an (incomplete) error.

For clarity, we will keep allowing simplifications of the unification of two concrete validators, like <3 & <5 to <3.

Full details here: https://github.com/cue-lang/proposal/blob/main/designs/language/3775-simple-validators.md

[tvandinther]

I agree with the 2nd point regarding simplification of non-concrete validators. For the first point, this does make sense to me only because it is kind of a unique side-effect of working within such discrete data types. This behaviour isn't even consistent with itself currently. Consider the following:

a: string
a: >"A"
a: <"C"

b: int
b: >1
b: <3

c: bool
c: !false

evaluates to:

a: >"A" & <"C"
b: 2
c: true

My expectation is that we get a: "B" from the simplification just as we get b: 2. Inverting that constraint (d: <"A" | >"C") correctly raises "B" as an error.

---

Are the examples in the full details completely correct? I do not observe the same evaluations in the CUE playground (or locally with evalv3).

For me the 2nd example would go:

min: *1 | int
// min: <max
max: >min

evaluating to

min: 1
max: >1

---

The following case, however, demonstrates some possibly undesirable simplifications:

min: *1 | int
min: <max
max: >min

In this case, it simplifies perhaps unexpectedly to

min: 1   // default taken
max: >1

What is the "expected" result in this example? I expect the behaviour since a preference is defined. I'm curious to know what other simplification could be expected or useful.

[mpvl]

My expectation is that we get a: "B" from the simplification just as we get b: 2. Inverting that constraint (d: <"A" | >"C") correctly raises "B" as an error.

"AA" would also be larger than "A", so "B" is not unique. But this indicates part of the problem. If we had another constraint that said that the string must be of length 1, then we could simplify it to "B".

In practice, the number of combinations where we could potentially do simplifications is large and it seems close to impossible, or at least a grand effort, to get it right. Consider for instance detecting that the unification of regular expressions produce a concrete result only: =~"^[ab]$" & =~"^[bc]$".

On the flip side, one actually could consider it a good property that unifying non-concrete values will not produce concrete values as a side effect. Taken this all in account, this seems that this is strictly an improvement.

[mpvl]

Are the examples in the full details completely correct? I do not observe the same evaluations in the CUE playground (or locally with evalv3).

The distinction is rather subtle. I would expect the example the fail, as both <max cannot be validated because field max is not concrete. Instead what happens is that <(>1) is "simplified" to int (between quotes as it is arguably incorrect). As a result, both disjunctions remain and the error is discarded.

So the difference is that in one case cue vet fails, whereas in the other case it succeeds.

With the following example, you can see the difference using cue eval:

#x: {
	min: *1 | int
	min: <max
	max: >min
}
y: #x
y: min: 3

With the old behavior, this results in

y: {
    min: 3
    max: >3
}

With the new behavior, this would be:

y: {
    min: 3 & (*1 | int) & <max
    max: >3
}

In other words, the unresolved <max restriction would not be discarded.

Arguably, in this case, we could safely discard <max. But it is hard to get this logic right and it often results in very unintuitive, and sometimes even arguably incorrect, behavior.