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]

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.

[tvandinther]

While the concept of the value-simplification-to-concrete feature is nice, I agree that it should be intuitive and work somehow on all sets. Given a theoretical solution can be found, the implementation as you mention is likely to be difficult. There is also something to be said for being explicit in making a value concrete which helps keep the distinction between the world of CUE and the world of real exportable data.

[mpvl]

Indeed it would be nice, and that is why it was there in the first place.

As an alternative, we could have a separate cue command to compete or suggest constraint resolution. This could then make suggestions when appropriate.

There are many more suggestions such a command could do. For instance, for

x: {
    a: b + 1
    b: int
}

it could suggest to complete this to

x: {
    a: b + 1
    b: a - 1
}

so that users could choose to file in either a or b, rather than having to fill in b.

The overall idea, though, is to keep the language simpler, and to do more complicated suggestions as separate tools.

[tvandinther]

The example you give is something I tend to aim for when writing CUE. A kind of "back propagation" of constraints, which I would argue is the "CUE" way. Putting this logic in a command could be useful but in particular, giving code hints via LSP would be the best case for such a feature. I.e. an info level underline on b: int suggesting to change it to b: a - 1 with reference to its co-constraints. Such a language hint could also suggest concrete values where these can be inferred, leaving it up to the CUE code author. It also means that logic for determining unique values could be built-up over time in a non-breaking way since it has been removed from the language spec.

At the same time, the cue trim logic can be given as type hints as well for if users want a more granular approach. I tend to commit my changes, then run cue trim to see exactly what it trims and whether it is desired but seeing it as code hints would be even better. Especially since many IDEs aggregate hints into lists/reports in a window somewhere.

In essence, removing this feature from the language doesn't mean it has to be removed from the developer experience entirely. The language server is a great candidate for hosting these conveniences.

[mpvl]

It is a good idea indeed to put such functionality in the LSP.

[mpvl]

This is now planned for v0.14. The implementation is currently in master.

[mpvl]

This has been running as default for a while. We will permanently enabled this for v0.15.