list concatenation gives export that doesn't satisfy definition
Spinoff from https://github.com/cue-lang/cue/discussions/1870#discussioncomment-3484927.
What version of CUE are you using (cue version)?
v0.4.3 web playground, and also verified with current tip:
$ cue version
cue version v0.0.0-20220829182706-ac1121593d7a
-compiler gc
CGO_ENABLED 1
GOARCH amd64
GOOS windows
GOAMD64 v1
vcs git
vcs.revision ac1121593d7ab5b3beff5b36f7e77e1cb3fab0c1
vcs.time 2022-08-29T18:27:06Z
vcs.modified true
Does this issue reproduce with the latest release?
Yes.
What did you do?
https://cuelang.org/play/?id=nRsy5wk2xJq#cue@export@json
! exec cue export d1870.cue
-- d1870.cue --
x: [...int]
x: x + ["foo"]
What did you expect to see?
An error, something like "conflicting values "foo" and int (mismatched types string and int)".
What did you see instead?
No error, and the exported value is {x: ["foo"]}, which is not an instance of (subsumed by) the original definition.
> ! exec cue export d1870.cue
[stdout]
{
"x": [
"foo"
]
}
FAIL: ... unexpected command success
BTW, I didn't find the definition of list concatenation (+ operator) in the language specification. I might have just missed it as I just did a quick scan and haven't read it in a while.
About not finding list concatenation in the spec, I instead found #1677 , which suggest removing list concatenation using the + operator, and mentions that it is already removed from the spec. I didn't manage to get trigger the bug using other ways (list.Concat or comprehensions both give give cycle errors).
Note: this is marked as comprehension as it has overlapping logic with the implementation of comprehensions and this will ensure this is validated against the upcoming changes for this.
About not finding list concatenation in the spec, I instead found #1677 , which suggest removing list concatenation using the + operator, and mentions that it is already removed from the spec. I didn't manage to get trigger the bug using other ways (
list.Concator comprehensions both give give cycle errors).
@antong and indeed, we are indeed considering removing support for + for lists, as its meaning is somewhat ambiguous and the same can unambiguously be achieved with comprehensions. And with the contemplated query extension it would be quite succinct too.
This has indeed been fixed by the recent changes. It may be underreporting error positions. A todo is still outstanding for this.