Open mvdan opened 5 days ago
I think this is working as intended.
In the struct case, you are embedding two structs (one being the #Schema
definition) into the file top-level struct/value. This works fine. If you add some explicit brackets, it becomes clearer why it passes:
{
#Schema: {
known: string
}
#Schema
known: "foo"
unknown: "bar"
}
As normal, when embedding a definition, yes, it closes the enclosing struct, but it doesn't reject any other fields that are statically there - that's an important difference between embedding a definition, and unifying with a definition.
With the list case, I'm less sure. I think the list case is equivalent to this:
#Schema: {
x: string
}
[string]: #Schema // same as saying "every element of the list must unify with #Schema"
known: {x: "hi", y: 7} // but this does fail
You're completely right about the struct case, my apologies. Let's focus on the list case, because that more closely resembles what the original user was doing, I just reduced the example a bit too much. Then our main testscript is this one:
env CUE_EXPERIMENT=evalv3=0
! exec cue export input.cue
env CUE_EXPERIMENT=evalv3=1
! exec cue export input.cue
-- input.cue --
#Schema: {
known: string
}
[...#Schema]
[{
known: "foo"
unknown: "bar"
}]
Which should succeed, but fails, as both the old and new evaluator accept the input. From my reading of the spec, they should fail, but I'm not sure.
I expect the testscript above to succeed -
unknown
should not be an allowed field given that#Schema
is a definition, and so it is a closed struct. However, both the old and new evaluator unexpectedly succeed:This is definitely wrong, particularly since placing the values under a field
foo
makes it work again:It is worth noting that the original example also unexpectedly succeeds when using a list: